Support & data completeness

The completeness caveat, stated plainly

The Partner API exposes records captured after the feature was enabled for that restaurant, in every collection. It does not claim to hold a restaurant's full history, and it will not backfill one. Deliveries are the one exception: their two collections carry the history the app still held when they opened.

This matters more than it sounds:

• An empty result is not evidence that nothing happened. It may mean the restaurant was not yet enabled, or that a device has not uploaded yet.
• A count from this API is not a compliance figure. Do not print one on a report that reads as an audit.
• If you need to know a restaurant's enablement date, ask us or ask the customer. It is not currently exposed through the API. If you need it as a field, tell us and it becomes one.

Collections say this in their own response: stateKind is received-shadow-snapshot, meaning the state this API received, not the state the restaurant's app holds. The two agree in the ordinary case and diverge exactly when a device has not uploaded yet.

Once a restaurant is enabled, records arrive reliably, including ones captured while a device was offline: those are uploaded when it reconnects, which is why incremental polling should overlap and why capturedAt and receivedAt are both on every record.

Versioning

Every path is prefixed /v1, and this API is in closed beta. Keys are issued by hand, to a handful of integrators, and the shape of the API is still being settled. Read that literally: inside /v1, while the beta lasts, an endpoint can change shape or be withdrawn, and we are not promising otherwise.

What that means in practice:

• Parse leniently. Ignore fields you do not know rather than failing on them; fields get added often.
• Watch for withdrawn endpoints. The dedicated delivery endpoints, and the scope that opened their photographs, are gone: deliveries are read as collections, like every other record type. See below.
• Tell us you exist. We know which keys have called us and when. If yours is in use we will get in touch before we move something under it, not because the beta obliges us to, but because breaking a working integration by surprise is a bad way to run one.

When the beta ends this section becomes the usual promise: additive changes inside a version, anything else behind /v2. It is not that yet, and saying so is more useful to you than a guarantee we would have to walk back.

The OpenAPI document is generated from the running service, so it is the authoritative description of what is deployed right now. If this documentation and that document disagree, the document is right and we have a page to fix. Please tell us.

Health checks

Two public endpoints, no authentication:

/health/ready is the one to poll if you monitor us. Successful probes are not audit-logged, so a monitor does not add noise.

Getting help

Write to contact@backresto.com. What makes an answer fast:

• the requestId from the problem document, or the X-Request-ID you sent;
• the public prefix of your key, the brp_… half before the dot, never the secret;
• the environment, the endpoint, and roughly when.

Never send us a key secret. The public prefix identifies it unambiguously. If a secret has gone somewhere it should not, say so in the subject line and send the prefix: revocation is immediate, and it is the whole remedy. See Getting a key for the rest of the key lifecycle.

Asking for more

What exists here exists because somebody asked for it. Cooking and cooling temperatures, cleaning plans, labels and a hosted MCP endpoint were all on this list a few months ago; they are now collections and an endpoint.

Deliveries were the last item on this list. They were the first thing this API served, through their own endpoints, with their own shape and a time range instead of a cursor. They are now two collections, deliveries and delivery-pictures, read through the same envelope, the same paging and the same GET .../collections/{collection}/records as every other record type, and the old endpoints are withdrawn rather than kept alongside. One way to read a record is the point of the change. If you built against the old endpoints, Deliveries shows the new shape, and we are happy to help you move.

What is still on it: webhooks instead of polling, an incremental cursor on collections, an enablement date on the restaurant, and OAuth sign-in for the MCP clients that will not take a key. Which one comes next is decided by who asks. So ask.