REST interface
Verified
In short
Section titled “In short”The REST interface lives at /api/v1 and answers GET only. Anything else gets 405 before the server even looks at the key.
Access is proven with a header — see the Overview.
| Endpoint | Scope | What it returns |
|---|---|---|
GET /account/entitlements |
account:read |
The client’s plan, features and limits with current usage. |
GET /affiliate/articles/:key |
affiliate:read |
One help article with its HTML wording in all or one language; variables not substituted. |
GET /affiliate/articles |
affiliate:read |
Help-centre articles of the partner portal: key, default/custom, enabled, order, per-language status. |
GET /affiliate/campaigns/:campaignId |
affiliate:read |
One affiliate campaign. |
GET /affiliate/campaigns |
affiliate:read |
Affiliate campaigns of a shop with reward, availability and counts. |
GET /affiliate/code-requests |
affiliate:read |
Partner requests for a custom discount code with state and reason; pending first. |
GET /affiliate/conversions |
affiliate:read |
Affiliate conversions of a shop with commission, state and link to the payout. |
GET /affiliate/discount-codes |
affiliate:read |
Partner discount codes on a shop with usage count and revenue. |
GET /affiliate/documents |
affiliate:read |
Programme documents (terms, agreements): confirmation policy, signed copy, e-mail attachment, versions per language, readiness and acceptance counts. |
GET /affiliate/email-templates |
affiliate:read |
Partner e-mail templates per language (subject, enabled, body with an event) and automatic attachments of the Account approved e-mail. |
GET /affiliate/links/generate |
affiliate:read |
Tracked affiliate link to the campaign shop home, a product or a category; keeps partner attribution after the click. |
GET /affiliate/partners/:partnerId |
affiliate:read |
One programme partner with the campaigns available to them. |
GET /affiliate/partners |
affiliate:read |
Programme partners with state, performance and commissions; contacts only with personal data. |
GET /affiliate/payouts |
affiliate:read |
Commission payouts to partners with state; without bank and billing data. |
GET /affiliate/portal |
affiliate:read |
Public partner portal: addresses per shop, registration openness with reason, custom domains, contact person, appearance and text status per language. |
GET /affiliate/settings |
affiliate:read |
Affiliate programme settings: commissions, clicks, payout minimum, referrals. |
GET /affiliate/statistics |
affiliate:read |
Affiliate statistics: daily timeline, attribution sources, partner ranking. |
GET /affiliate/summary |
affiliate:read |
Affiliate programme overview of a shop for a period: clicks, conversions, commissions, partners. |
GET /analytics/channels |
analytics:read |
Traffic channels including ChatGPT and other AI sources. |
GET /analytics/order-coverage |
analytics:read |
Order coverage by tracking. |
GET /analytics/overview |
analytics:read |
Visits, orders, revenue, conversion rate, AOV, share of AI sources. |
GET /analytics/seo |
analytics:read |
Search Console by query or page. |
GET /automations/catalog |
automations:read |
Automation catalogue: triggers, condition fields, operators, actions, templates and catalogVersion. |
GET /automations/:workflowId |
automations:read |
One automation with DSL and validation result. |
GET /automations |
automations:read |
The client’s automations with state and shop scope. |
GET /automations/:workflowId/runs |
automations:read |
Run history of one automation. |
GET /automations/templates |
automations:read |
Ready-made automation templates with DSL. |
GET /claims/:code |
claims:read |
One claim with items, refunds and return shipments. |
GET /claims |
claims:read |
Claims and returns of one shop with links to the order. |
GET /claims/settings |
claims:read |
Claim processes (types, steps, statuses, deadlines); module settings only with the right to them. |
GET /claims/statistics |
claims:read |
Claims and returns statistics for a period: counts, resolution times, types, ratings, reasons. |
GET /content/articles |
products:read |
Blog articles and shop content from the canonical mirror by title or text. |
GET /coupons/activation-link |
coupons:read |
A link that applies an EXISTING coupon in the customer’s cart. Does not create coupons. |
GET /coupons/activation-status |
coupons:read |
Whether a coupon can be used on the shop via the activation link: coupon mirror + web code status. |
GET /coupons/capabilities |
coupons:read |
What the shop’s platform can do with coupons. Read before creating. |
GET /coupons/:code |
coupons:read |
One coupon by code. |
GET /coupons |
coupons:read |
The shop’s discount coupons with discount type and amount, validity and derived state. |
GET /customers/:customerKey |
customers:read |
One customer from the directory — identity, shops, lifetime and optional period money, broken down per shop. |
GET /customers |
customers:read |
Customer directory: identity (with personal-data masking), shops, language, lifetime counts and revenue by currency; optional purchase-activity filter for a period. |
GET /customers/performance |
reports:read |
Customers as pseudonyms: orders, revenue, LTV, new and returning. |
GET /credit-notes |
invoices:read |
Search in credit notes. |
GET /invoices/:invoiceCode |
invoices:read |
One invoice with document items, credit notes, proforma invoices and the order number. |
GET /invoices |
invoices:read |
Search in invoices. |
GET /inventory/movements |
inventory:read |
History of stock movements: when, what, how much, kind, origin, order. |
GET /inventory/availability |
inventory:read |
Stock level of several items at once. |
GET /inventory/stock |
inventory:read |
Stock level of one item including the source of the value. |
GET /orders/:orderCode |
orders:read |
One stored order including items. |
GET /orders |
orders:read |
Stored orders of one shop, newest first. |
GET /categories |
products:read |
Shop categories with product counts. |
GET /products/:code |
products:read |
One product by code including category and the price from the card. |
GET /products |
products:read |
Product search by name, code, EAN or PLU. |
GET /reports/financial-summary |
reports:read |
Financial summary of a period; with purchase-prices:read also cost of goods, gross profit and margin. |
GET /sales/order-performance |
reports:read |
Revenue per order with totals for the whole period; with purchase-prices:read also cost, profit and margin. |
GET /sales/product-performance |
reports:read |
Sales per product with totals for the whole period. |
GET /shipping/carriers |
shipping:read |
Connected carriers and profiles, without credentials. |
GET /shipping/shipments/:shipmentId |
shipping:read |
One shipment with all tracking events. |
GET /shipping/shipments |
shipping:read |
Shipments with carrier, country, hand-over and delivery time, paged. |
GET /shipping/stats |
shipping:read |
Delivery statistics per carrier: counts, success rate, median and p90 delivery time, countries. |
GET /stores/integration-status |
stores:read |
MitoOps web code status per shop: installed, version, modules, readiness of coupon-from-link. |
GET /stores |
stores:read |
The client’s shops with their code. |
GET /suppliers/:supplierId |
purchasing:read |
One supplier with offers and cost components. |
GET /suppliers |
purchasing:read |
Suppliers with offers and cost components. |
GET /webhooks/endpoints/:endpointId/deliveries |
webhooks:read |
Delivery log of one endpoint without bodies. |
GET /webhooks/endpoints/:endpointId |
webhooks:read |
One webhook endpoint with the number of pending deliveries. |
GET /webhooks/endpoints |
webhooks:read |
The client’s webhook endpoints without secrets and the queue state. |
GET /webhooks/events |
webhooks:read |
The catalogue of outbound webhook events, envelope and signature. |
| Endpoint | Scope | What it returns |
|---|---|---|
GET /capabilities |
— | what this key is allowed to call |
GET /openapi.json |
— | the machine-readable contract |
GET /capabilities is the fastest way to find out what a key opens — it returns exactly what its scopes allow, not the whole catalogue. The exact parameters and response fields of every call are in openapi.json.
Response shape
Section titled “Response shape”Every response has two parts: data and meta.
{ "data": [ { "market": "sk", "name": "My shop" } ], "meta": { "requestId": "…", "count": 1, "hasMore": false, "nextCursor": null }}meta.requestId identifies the call. If something goes wrong, it is the value that tells support which call you mean.
Pagination
Section titled “Pagination”Ask for the next page by sending the nextCursor from the response back in the cursor parameter. Every other parameter must stay the same — a cursor belongs to the query it came from, and with a different store or period the interface rejects it (400). Tell the end by hasMore, not by the number of records returned. An invalid cursor is an error, not an empty result: an empty response would look like the end of the data and an export would quietly come up short.
There are deliberately no page numbers: when a record is added between two calls, “page 2” no longer points where it did a moment ago.
Listing and searching
Section titled “Listing and searching”For products, invoices and credit notes these are two modes of one address: without query you get a page-by-page listing, newest first (paginated, and it can be restricted by period); with query you get a search ordered by relevance (at most limit records). Search is neither paginated nor restricted by period — combining query with cursor, from or to returns 400 rather than silently ignoring the filter. To read out the whole record set, use the listing without query.
Period
Section titled “Period”Orders, documents, shipments, statistics, analytics and reports can be restricted with from and to in YYYY-MM-DD form.
- Both bounds are inclusive.
to=2026-08-05covers all of 5 August, not midnight at its start. - The day is taken as the store sent it — in its own time zone, the same way staff see it in the application.
- Orders are ordered by the date the order was placed, shipments by the date the shipment was created.
- Invoices and credit notes by the tax date; where a document has none, by its issue date. This is the same semantics the application uses to assign documents to periods. Which value placed the document is visible in the
businessDatefield. - Sales per product by the document date; here the period is required.
- The longest period is 366 days. Anything longer is rejected.
- Without a period shipments and statistics return the last 30 days, analytics and the financial summary the current month. The response always states the period.
- A reversed period is an error, not an empty result — otherwise a typo would look like a period with no documents.
Orders still accept todayOnly. It cannot be combined with from/to: they are two answers to the same question.
What the financial fields mean
Section titled “What the financial fields mean”purchasePriceWithoutVaton an order item is the purchase price at the time of the order, as the shop stored it. It is not the price from today’s product card — that one ispurchasePriceinproducts/{code}.cogsin the financial summary is the cost of goods for the period from all orders;nullmeans purchase prices are not known for enough lines (cogsCoverage). Gross profit is then not shown either — nothing rather than a wrong figure.grossProfitis revenue without VAT minus cost of goods,grossMarginthe same in percent.resultAfterCostsis gross profit minus shipping minus company costs — a management figure, not accounting profit.- In sales per product,
purchaseCostWithoutVatis the purchase cost at document time from matching with the catalogue;unmappedLinessays how many lines did not match. - All report and analytics amounts are in EUR (field
currency), converted at the rate at sync time. Orders and documents carry their own currency.
Without the purchase-prices:read scope these fields are absent from the response — not zero, absent.
Delivery time
Section titled “Delivery time”Delivery statistics (shipping/stats) measure the time from hand-over to the carrier to the first delivery event in the tracking events. Nothing is computed from the order date. A shipment lacking either point is not counted in the median; delivery.measured says how many were. Every shipment carries the same two times in handedOverAt and deliveredAt.
deliveryRate is the share of delivered shipments among those whose fate is settled (delivered, returned, failed). A shipment in transit is neither a success nor a failure yet; a cancelled shipment is your action, not the carrier’s failure, and is not counted at all.
Stock levels
Section titled “Stock levels”inventory/stock returns quantity and source — which stock model the value comes from (variants, the shop’s balance, the product card). When the shop keeps a balance, physical, available (available for sale) and reserved (reserved in orders) are available too; otherwise they are null. The interface invents no “on hand” figure the application does not keep.
Customer directory
Section titled “Customer directory”Customers have two different reads, and mixing them up means reading a different number than you expect:
/customersand/customers/{customerKey}(scopecustomers:read) are the directory: the same projection the staff sees on the Customers screen and the one that goes into the export — identity, shops, country, language, counts and dates./customers/performance(scopereports:read) is analytics over raw orders: the customer is only a pseudonym, with no name or contact in it at all.
From outside, market is required for both. Without it the read would span every shop of the client, including the ones this access does not cover.
Who sees what
Section titled “Who sees what”customers:read on its own returns the pseudonym (customerKey), shops, country, language, order counts and the dates of the first and last order. On top of that:
- name, company, e-mail, phone and marketing gender only with
personal-data:read, - revenue, average order and LTV only with
reports:read.
Fields you have no scope for are removed, not zeroed. A null where the e-mail sits would mean “this customer has no e-mail”, which is not true — a missing key means “you have no right to it”.
customerKey is the SHA-256 of the normalised e-mail. It is the same pseudonym that documents carry (customerEmailHash) and that /customers/performance uses, so the three views can be joined without sending an e-mail address anywhere.
Lifetime versus period
Section titled “Lifetime versus period”The directory has an optional purchaseFrom / purchaseTo filter (YYYY-MM-DD, both bounds inclusive). It means purchase activity in the period: the customer has at least one order in that interval. It is not a filter on the date of the first or last purchase.
With a period, the fields periodFrom, periodTo, periodOrdersCount and periodRevenueByCurrency appear next to the lifetime ones (ordersCount, revenue, lifetimeRevenue, firstOrderAt, lastOrderAt) — never instead of them. Lifetime values do not change with the period.
Money is always per currency
Section titled “Money is always per currency”Revenue, average order and LTV are an array per currency, never a single number. A customer with orders in both EUR and CZK has two entries; adding them into one scalar would mean adding korunas to euros. The same holds for /customers/performance: a row is a (customer, currency) pair and the filter totals are totals.revenueByCurrency.
Language and marketing gender
Section titled “Language and marketing gender”languageis the language of the shop the customer ordered from (source: "store_locale"), not their own choice. The application does not record an explicit language preference of the customer today.marketingGender(male/female/unknown) is an inference from the first name, not something the customer stated. The origin is always ingenderSource— today exclusivelyname_inferenceorunknown— and the confidence ingenderConfidence. A company customer does not have the field. Anyone displaying it further should say “inferred from the name”, never “the customer stated”. It sits behindpersonal-data:readjust like the name itself.
Calls over a single shop’s data require its code in the market parameter. GET /stores returns the list of codes.
When the key has no scope for that shop the answer is 403 — not an empty list. An empty list could not be told apart from a shop with no orders. A record of another shop (for example a shipment) is 404.
Errors
Section titled “Errors”An error response always has the same shape and carries a code. The list of statuses is in the Overview.
Examples
Section titled “Examples”# Orders for a period, pagedcurl -H "Authorization: Bearer <your key>" \ "https://<your address>/api/v1/orders?market=sk&from=2026-08-01&to=2026-08-31&limit=50"
# Delivery statistics for Augustcurl -H "Authorization: Bearer <your key>" \ "https://<your address>/api/v1/shipping/stats?market=sk&from=2026-08-01&to=2026-08-31"
# Financial summary of August (with the purchase-price right also gross profit)curl -H "Authorization: Bearer <your key>" \ "https://<your address>/api/v1/reports/financial-summary?market=sk&from=2026-08-01&to=2026-08-31"
# Stock levels of three itemscurl -H "Authorization: Bearer <your key>" \ "https://<your address>/api/v1/inventory/availability?market=sk&codes=A100,A101,A102"