Stay up-to-date with the latest changes and improvements to the Eshop-rychle API
Subscribe:
Added the invoiceCreate, invoiceChange and invoiceDelete webhooks, covering all four document types — invoice, credit note, advance invoice and payment receipt; documentType says which one. Documents are batched per e-shop and de-duplicated. The payload carries only IDs — fetch the current data via GET /api-engine/invoices/{id} (a deleted document returns 404). If a notification is missed, GET /api-engine/invoices with invoiceChanged[after] lists everything touched since your last read. Fires only if the package and API access are allowed to read orders, and nothing reaches you until you register the type.
Creating a sub-resource with some text fields left out, or creating one that already exists, failed with a bare 500. Both now return 422 naming the field or the conflict.
Documents now carry peppolReportedAt — the moment the document was handed over to the e-invoicing (Peppol) network. Read it on GET /invoices, set or clear it with the new PATCH; it is the only writable field. Once set, the administration warns the merchant before editing the document, so what you reported stays in sync.
GET /product-videos now accepts the product query filter (UUID or IRI, plus id for completeness), matching what /product-images already offers with productItem. Until now the parameter was silently ignored and the collection always returned all videos of the e-shop.
Query filters now carry real descriptions, types and allowed values in the docs. Two of them stopped ignoring nonsense: documentType on /invoices and registrationMethod on /customers reject an unknown value with 422 instead of quietly returning unfiltered data. Everything else on the wire is unchanged.
Added the customerRetentionDelete webhook, sent when a registered customer is erased once the GDPR retention period expires. Not customerDelete — the customer did exist and their orders stay, so drop their personal data but keep them in order history and statistics. Batched per e-shop, at most 500 per message. Register the type to receive it.
isVisible: false was refused as an empty value, so a product origin of type SUPPLIER could not be created at all. It is accepted now.
Requests sent as application/json failed with a bare 500. They now return 406 or 415 naming the supported types.
Added the orderRetentionDelete webhook, sent when orders are erased once the e-shop's GDPR retention period expires — until now this happened silently. Deliberately not orderDelete, which means the merchant invalidated the order: a retention delete means the order did happen and is only being erased. Discard your stored copy, but do not subtract it from revenue or statistics. The invoices and other documents of the order go with it — drop them by the order ID. Orders are batched per e-shop, at most 500 per message. Nothing reaches you until you register the type.
GET and PATCH /api-engine/price-configs now also carry the five VAT rates of the e-shop, vatRate1 to vatRate5, plus shippingVatId saying which of the five slots applies to shipping. A product points at a rate by its slot number (vatId 1 to 5), so this is the only place to find out what a vatId actually stands for. Rates are in percent and accept 0 to 99.9 with at most one decimal place; a slot set to 0 is simply unused. Only the fields present in a PATCH body are changed, the rest keeps its current value. Changing a rate does not recalculate anything — the products in that slot are taxed at the new rate from then on.
New GET and PATCH /api-engine/price-configs with priceEntryMode: withVat or withoutVat. It tells you which base product prices use, so read it before sending prices in. Switching it does not recalculate the prices already stored.
Order states now carry systemType: newOrder (unprocessed) or completeOrder (fulfilled), exactly one of each per e-shop. All the other states belong to the e-shop owner — do not rely on their names, count or order.
The source field of productCreate, productChange and productDelete reported system for changes caused by a customer order, so the documented order value never actually reached you. Stock write-offs made when a shopper completes an order in the storefront are now tagged source: order as documented. Sales rung up at the in-store cash register get the new value cashdesk, so you can tell them apart from storefront orders — the payload carries product IDs only, so this tag is the only way to distinguish the two. Nothing else in the payload changed. If you branch on source, expect order where you have so far been seeing system, and treat any unrecognised value as system: the list can grow again.
Added GET /api-engine/feeds, which lists every product feed available for the e-shop — including the ones not turned on yet — with its public url and when it was last generated. POST /api-engine/feeds with {"name": "heureka_cz"} turns a feed on and queues a single generation; it answers 202, so poll GET /api-engine/feeds/{name} until generationTime fills in. The feed itself is downloaded from url, not through the API.
Discount coupons are no longer limited to the whole order. The new type and subtype fields say what a coupon applies to: type product with all_product, selected_product or selected_category, and type shipping with all_shipping or selected_shipping for free or discounted delivery. Coupons limited to a selection carry it in the matching collection — products and categories reference products and categories by IRI, shippings references delivery methods by the UUID from GET /api-engine/delivery-methods. Sending one of these collections replaces it as a whole; omitting all three keeps the current ones. Existing integrations are unaffected: leave type and subtype out and the coupon applies to the whole order exactly as before.
Product blocks in the frontend dataLayer (product, cart.items[], order.items[], and the cartUpdated product) now carry productNumber and ean, so you can match an item against your own catalogue or feed instead of relying on our internal id. Variants are additionally exposed as variantOptions — a machine-readable [{ name, value }] list, next to the existing variant string, which could not be split reliably because it carried no option names and its separator can occur inside a value. Order lines also gained the variant string itself. All fields are additive, so the contract stays at version 1.0. Note that on an order productNumber is stored at checkout time, while ean is read from the current catalogue and is null if the product has since been deleted.
Added customerCreate, customerChange and customerDelete webhooks. Active API users are notified whenever a registered customer is created, their registration data changes (name, phone, billing details, …), or they are deleted — from the admin, the storefront account, the API or imports. Notifications are batched per request and de-duplicated, so a single call can carry multiple customers. The payload contains only customer IDs; fetch the current data via GET /api-engine/customers/{id} (a deleted customer returns 404). Each webhook fires only if the API access is allowed to read customers.
Shops now expose a neutral, versioned frontend contract (window.dataLayer[0].eshop + events: pageVisit, loggedUser, cartUpdated, orderSubmitted, cookieConsent). Partners hook their own JS loader onto it via a CustomCode add-on — no per-partner code on our side. Consent is handled by the partner loader itself through a neutral runtime consent signal. See the Frontend dataLayer page for the full schema, events and versioning.
Outgoing webhooks can now be signed so you can verify they really came from us and were not altered in transit. Generate a signing key in the API administration (section „Zabezpečení webhooků") and every webhook is then sent with the X-Webhook-Signature header (sha256=<hex>, an HMAC-SHA256 of timestamp + "." + raw body) and X-Webhook-Timestamp. Signing is opt-in — without a key webhooks are sent unsigned as before — and the key can be rotated without downtime.
Added the packageOpenInstructions webhook. Whenever a shop admin opens the installation instructions of an add-on, active API users receive a system webhook notification.