Getting a key
How to ask for a Partner API key, what to put in the request, and what comes back.
Partner keys are issued by hand. Fill in the form below — or email us, which reaches the same people — and we provision the credential and send it to the contact you name.
A person reads every request, because a key carries access to a restaurant's compliance records and the restaurant has to have agreed to it. What that costs you is a reply rather than a redirect; what it buys is that nobody can mint themselves access to someone else's data. The form asks for everything we need to act on it in one go.
Who can ask
Either side, but the restaurant has to agree either way.
- You, the integrator. Say which restaurants you need and name your contact there; we confirm with them before issuing anything.
- The restaurant. They ask on your behalf and name you. This is the faster path, because the confirmation has already happened.
We will not issue a key for a restaurant that has not agreed to it, and we will not widen an existing key without asking them again.
Request a key
If you are integrating for several restaurants that belong to different customers, send one request per customer. One key per customer keeps a revocation from taking down every other integration you run.
Two of the fields are worth a note. Environment matters because keys and data are per-environment — a production key means nothing on pre-production, so say if you want to build against pre-production first. And scopes should be what you use rather than everything: there are twenty-six of them, one per collection plus deliveries and their photographs, and the restaurant reads the list before agreeing to it. Naming the four you need gets a faster yes than asking for all of them; see Authentication for what each one opens.
Already hold a key and want a collection it does not reach? That is the same email, and an extension rather than a new key: your secret does not change and nothing needs redeploying.
Prefer to write it yourself? contact@backresto.com with the same details reaches the same inbox.
What comes back
A single value, of the form brp_<prefix>.<secret>, sent to the technical
contact you named.
Store it on arrival and delete the email. We keep only the public prefix and a digest of the secret, so we cannot resend it — if it is lost we revoke that key and issue a new one, which means another round trip.
Keys do not expire on their own. They stay valid until revoked, which is why the answer to "someone left the team" is a rotation, not a shrug.
Changing a key later
All of these are an email, and all of them need the restaurant's agreement where they widen access:
| Ask | What happens |
|---|---|
| Add a restaurant or a scope | We extend the existing key. Your secret does not change and nothing needs redeploying. |
| Rotate | We issue a second key first, you deploy it, then we revoke the old one. No window where neither works. |
| Revoke | Immediate. The next request with that key answers 401. |
| A time-limited key | Say so in the request — for a one-off audit or a proof of concept, a key that dies on its own is safer than one you have to remember to kill. |
For anything urgent — a leaked secret above all — write to
contact@backresto.com
with the key's public prefix (the brp_… half before the dot) and say it is
urgent. Never send us the secret itself, not even to prove which key you mean.
While you wait
Nothing in the documentation needs a key to read, and the shapes are all on these pages: the delivery record, the photographs, collections and records, the error model and pagination. The OpenAPI document is public too, so you can generate a client and write against it before the key arrives.