For the storefront developer
What the public API does, how the key works, why an order cannot be duplicated, and how to get the full specification.
This page is for whoever builds the storefront. It covers the approach and the rules; the full specification — endpoint addresses, fields and examples — is handed over together with the key, on request from the venue or its developer.
A method list published on a marketing site helps whoever is hunting for other people’s integrations more than it helps an integrator. A developer needs it once and gets it within minutes; a crawler does not need it at all. Ask us and you will have it the same day.
Authorisation
Access is by integration key. A key belongs to exactly one venue: another venue’s data is unreachable by design, not by a check buried in the code.
- the key is issued by the venue in the back office and shown once;
- the secret part is stored as a hash — it cannot be recovered, only reissued;
- revocation is immediate: a revoked key stops working from the next request;
- the key lives on the storefront server. It does not belong in the guest’s browser, in a mobile app, or in a repository.
If a key ends up in a group chat, a public repository or client-side code — revoke it and issue a new one. It is one button, and far cheaper than the alternative.
What the integration can do
| Capability | What the storefront gets |
|---|---|
| Menu | Categories, dishes, prices, modifiers, photos — already without suspended items |
| Order intake | The order goes out in one call and gets a number back |
| Change and cancel | While the venue has not accepted the order yet |
| Voucher validation | The discount is calculated the same online and at the register |
| Payment notification | A payment taken on the storefront maps to the venue’s payment method |
| Intake flag | Whether the venue is accepting orders right now |
| Statuses back | Accepted, cooking, handed to courier — callbacks go to the storefront, signed with a shared secret |
Idempotency
The storefront attaches its own operation key to every order. Resubmitting with the same key never creates a second order — that covers double taps, dropped connections and queue replays.
The practical consequence: after a timeout, do not be afraid to repeat the request. Be afraid of the opposite — generating a fresh operation key for the same guest order.
What matters when building
- items are identified by code, not by name: names change, codes do not;
- modifiers are sent separately from the dish, with their own codes and prices;
- the line price is money: the server verifies it and does not guess;
- the stop-list is live: request the menu before rendering it, do not cache it for a day;
- an unanswered mandatory choice is not a rejection — the order still arrives and the manager picks the option;
- request rates are limited, and repeated voucher misses hit a separate guard. Neither gets in the way of a normal storefront; a brute-force loop runs into them immediately.
Errors
Error responses are descriptive: they name the line that failed and why. Log the full response body during integration — it saves hours of correspondence.
The one exception is an invalid key: that returns a short response with no detail. This is deliberate, so that the shape of the error cannot tell an attacker whether a key was valid.
Pre-launch checklist
- Fetch the menu and render it, stop-list included.
- Submit a test order and see it appear in the register panel.
- Resubmit with the same operation key and confirm no second order appears.
- Validate a voucher — a valid one and an expired one.
- Report a payment and confirm the order closes with the right payment method.
- Test a dropped connection: cut the response mid-flight and repeat the request.