Rate limits

The Partner API allows 300 requests per minute per key. The window is a rolling minute, and the budget belongs to the key rather than to the restaurant or to your company, so two deployments with two keys have two budgets. The MCP endpoint draws on the same budget: one tool call is one request.

Going over answers 429 with a problem document of type rate-limit-exceeded and a Retry-After header giving the number of seconds until the budget refills. Wait it out; do not retry sooner, because a request that arrives early consumes budget without succeeding.

Retry-After is the only budget header. There is no X-RateLimit-Remaining to watch, so pace your client by design rather than by reading a counter — the habits below are that design.

Staying under it comfortably

Three habits cover almost every integration:

Ask for full pages. limit=100 fetches the same day of deliveries in a quarter of the requests that limit=25 needs. The cost of a request is the request, not the row count.

Fetch photographs only when you need them. A delivery carries an imageCount. If it is 0, there is nothing behind the images endpoint, and calling it is a request spent on an empty list.

Serialise a backfill. Walking a year of history with ten workers in parallel is the one shape that reliably hits the limit. One worker at limit=100 moves through a busy restaurant's year in a couple of minutes.

If you genuinely need more

Tell us what the workload is. The limit exists to keep one misbehaving client from degrading the service for the restaurant whose data it is, not to ration access; a described, legitimate workload is a conversation, not a refusal.

The other limits worth knowing

These are enforced by the API rather than described by it: exceeding any of the first three answers 429 or 400 rather than quietly truncating.