# Support & data completeness

> What the current data does and does not cover, how the API is versioned, and how to reach a human.

Source: https://developers.backresto.com/en/docs/support

## The completeness caveat, stated plainly

The Partner API exposes records captured **after the feature was enabled for
that restaurant**, in every [collection](https://developers.backresto.com/en/docs/collections). 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](https://developers.backresto.com/en/docs/pagination) 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](https://developers.backresto.com/en/docs/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](https://api.backresto.com/openapi.json) 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:

| Endpoint | Meaning |
| --- | --- |
| `GET /health/live` | The process is running. |
| `GET /health/ready` | The process can reach its database and serve traffic. |

`/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](mailto: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](https://developers.backresto.com/en/docs/access) 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](https://developers.backresto.com/en/docs/collections) and
[an endpoint](https://developers.backresto.com/en/docs/mcp).

**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](https://developers.backresto.com/en/docs/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.