This is the API powering Omnia 2.0 and Pricemonitor, containing operations that can also be used directly by customers from their own systems.
Omnia 2.0 API (0.0.7213)
The Omnia 2.0 API is RESTful and provides access to the backend of Omnia 2.0 and Pricemonitor. It is used to manage products, offers, contracts, and more.
This API supports both public endpoints for customer integration and internal endpoints for platform management. All endpoints are authenticated using either Basic Authentication or JWT Bearer tokens.
Download OpenAPI description
Overview
Languages
Servers
Mock server
https://api-docs.omniaretail.dev/_mock/api/omnia/
Production API
https://api.patagona.de/
The Omnia 2.0 API (also known as the Pricemonitor API) gives access to the superpowers behind the Omnia Retail platform.
The Omnia 2.0 app and the Pricemonitor app are the main consumers of this API, but we also have endpoints available to customers to integrate the API directly with their own systems.
These are the common API operations for customers to integrate Omnia with their own systems:
- Retrieve market data
- Retrieve price recommendations
- Manage your product assortment
- Provide offers for custom sources
Omnia supports four patterns for pulling data. Choose the one that best fits your latency and operational needs.
| # | Pattern | When to use |
|---|---|---|
| 1 | Continuous polling (preferred) | Near‑real‑time feed with minimal peak load |
| 2 | Full data export | Point‑in‑time snapshots or back‑fills |
| 3 | Webhooks (callbacks) | Push notifications after a price‑calculation run |
| 4 | Task‑based export | Poll a task until succeeded, then fetch data |
Why polling is preferred
Continuous polling evens out traffic, avoids large "catch‑up" imports and delivers data as soon as it becomes available.
All polling examples use 15‑minute, aligned windows and a page size of 1,000 items. This combination has proven to be the sweet‑spot between freshness and throughput.
- Alignment rule – round the current time down to the nearest quarter hour (
:00,:15,:30,:45).
Example: If it is12:23, the aligned time T is12:15. - Window –
endDate = T − 15 min,startDate = endDate − 15 min. - Next run – repeat every 15 minutes; no need to persist
startDatebecause it is derived from the current time.
| Runtime | startDate | endDate |
|---|---|---|
| 12:00 | 11:30 | 11:45 |
| 12:15 | 11:45 | 12:00 |
| 12:30 | 12:00 | 12:15 |
| … | … | … |
Use this pattern when you need the entire dataset for a specific point in time.
Call the corresponding endpoint and page through the result set exactly as shown in the pagination section below.
Omnia can send an HTTPÂ POST callback as soon as a price calculation task finishes.
This push‑style integration is optional and complements the polling patterns.
Use GET /api/v3/vendor/contracts/{contractId}/offers to fetch the newest offers in the market as described here.
- Align to 15‑min window
T = now rounded down to the nearest:00 / :15 / :30 / :45endDate = T − 15 min,startDate = endDate − 15 min - Request
GET /api/v3/vendor/contracts/{contractId}/offers?startDate={startDate}&endDate={endDate}&limit=1000&start=0 - Page
Repeat withstart=1000,2000,…until the response contains < 1000 items. - Schedule
Repeat every 15 minutes.
Use GET /api/2/v/contracts/{contractId}/result/pricerecommendations to fetch calculated prices as described here.
- Align to 15‑min window (same logic as above)
- Request
GET /api/2/v/contracts/{contractId}/result/pricerecommendations?startTime={startDate}&endTime={endDate}&limit=1000&start=0 - Page
Repeat withstart=1000,2000,…until the response contains < 1000 items. - Schedule
Repeat every 15 minutes.
Tip – Market data and price recommendations share the same window logic, so both polls can be executed by the same cron job.
Use this operation to retrieve products via a query. It supports returning paged results. We recommend to retrieve with a page size of 10,000 products.
Use this operation to upload your product assortment in JSON format. We recommend that you provide your product data in multiple parts via sequential requests to this endpoint. After providing all data, you need to delete the old data via this operation by specifying a timestamp just before your import.
If you cannot use the JSON format, as a fallback, we support uploading your product assortment to our system in CSV format via this operation.
API endpoints can potentially return a lot of items. Returning all data as one response to one request can overload the server, the database or the client. Returning all items may even be unnecessary when the client is only interested in the top N entries. So API operations that could return a lot of data support pagination. The pagination approach used in the latest version of API operations is described here.
Operations that support pagination:
- Return a subset of all matching items based on parameters in the request. Such a subset is called a page.
- Return the requested page as an array within a
dataobject within the response. - Can return all matching items by subsequently requesting multiple pages.
There are no subsequent matching items if the number of items in a response is smaller than the requested limit.
This parameter defines how many items are returned at most in a singe response. This is also called the page size.
The API documentation states the range that is allowed to be specified by the client.
This parameter defines from which item in the total result set this request wants data to be returned. It basically defines what page should be returned. The index of the first item is 0. If the value of start is beyond the number of matching items, an empty data array is returned in the response.
Pagination itself only works when the entries have a stable sorting. This is the responsibility of the API.
The API supports two authentication methods with distinct use cases: basic authentication and JWT bearer token authentication. For more details see below.
In short: for API integration with other systems or to explore the API, use basic authentication.
Security Scheme Type: HTTP
HTTP Authorization Scheme basicUsed for:
- API integration with other systems, like customer systems or plugins in webshops.
- Exploring the API interactively via the API tester in the documentation.
The API password is:
- Generated for Omnia 2.0 users via the API access feature. Available in the user drop down menu top right in the Omnia 2.0 application.
- For Pricemonitor users the same password they use to sign in to Pricemonitor.
Note: For Omnia 2.0 users the API password is a different password than what is used for interactive logon to the web application. Also Single-Sign On users can generate an API password via the API access feature in Omnia 2.0.