Introduction
What the BackResto Partner API exposes today, what it deliberately does not, and who decides.
BackResto is the HACCP compliance app food-service teams fill in during service: goods-in checks, cooking and cooling temperatures, cleaning plans, labels. The Partner API hands that record to the software your customers already run — an ERP, a supplier portal, a quality dashboard, an AI assistant.
It is a read-only HTTP API with one authentication scheme and one error shape,
described end to end by an
OpenAPI document you can load straight
into a client generator or an LLM tool definition. The same data is reachable
over MCP at https://api.backresto.com/mcp, with the same key and
the same permissions, if what you want is to ask questions rather than write a
client.
The restaurant decides what you see
This is the part worth reading twice, because it is different from most APIs you will integrate with.
There is no sign-up. A key is issued by hand, scoped to named restaurants and named scopes, and only once the restaurants in question have agreed to it. Ask for one by email — Getting a key is the checklist — and it arrives at the technical contact you name.
The consequence is a firm one: a key reaches the restaurants it was granted and
nothing else. restaurant-3 does not appear because restaurant-1 and
restaurant-2 are on the same key, and no request you can make widens that.
Adding a site is another conversation, with the people whose data it is.
The upside of a small manual step is that revocation is just as direct: one email and the key is dead on the next request.
What is in the data
| Resource | What it is |
|---|---|
| Deliveries | One record per goods-in check: supplier, compliance verdict, non-compliance reasons, corrective actions, free-text commentary and a temperature reading per product. |
| Delivery photographs | The pictures taken at reception, served as short-lived signed URLs. |
| Collections & records | Twenty-four further record types — temperatures, cooling, freezing, reheating, transport, cleaning, fryer checks, surface analyses, traceability labels, drive files, and the equipment and people behind them. |
Deliveries are a designed resource; collections hand you the record as the app holds it, in one generic envelope. The second is how a module reaches this API the week it ships rather than the quarter after.
All of it is read-only. Nothing a partner key can call writes to a restaurant's records — the app is where compliance data is created, by the person who is accountable for it.
What is not here yet
Being explicit about the edges saves you an afternoon:
- No historical backfill. A restaurant's records become visible to this API from the moment capture is switched on for that restaurant. What came before is in the app, not here. Do not treat an empty range as proof that nothing happened — see Support.
- No writes, no webhooks. You poll. If you need to be pushed to, tell us; it is a question of demand, not of principle.
- No incremental cursor on collections. Refreshing a collection means
walking it again and reconciling on
id. Deliveries, which are immutable, take a time range instead. - No OAuth sign-in. Every client authenticates with a key, including over MCP. Tools that insist on a sign-in page cannot connect yet.
Base URLs
| Environment | Origin |
|---|---|
| Production | https://api.backresto.com |
| Pre-production | https://api-preprod.backresto.com |
| Development | https://api-dev.backresto.com |
A key is provisioned in one environment and means nothing in the others: keys, grants and data are per-environment. Everything below uses the production origin.
Ready? Make your first call.