Support & data completeness

The completeness caveat, stated plainly

The Partner API exposes records captured after the feature was enabled for that restaurant — deliveries and collections alike. It does not claim to hold a restaurant's full history, and it will not backfill one.

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. Within that version we will:

• add fields to a response, and
• add endpoints and optional parameters.

Both are backwards-compatible, and neither will be announced as a breaking change — so parse leniently: ignore fields you do not know rather than failing on them.

We will not remove or retype a field, change the meaning of an existing one, or make an optional parameter required, inside /v1. Anything that needs to would arrive as /v2, alongside /v1, with notice.

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.

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.