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 walks the same collection in a quarter of the requests that limit=25 needs. The cost of a request is the request, not the row count.

Fetch files only when you need them. A picture's record already says what the file is, in data.asset: type, size and digest. Call the assets endpoint for the pictures you are about to show or store, not for every record in a walk, and skip the ones whose sha256 you already hold.

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 either of the first two answers 429 or 400 rather than quietly truncating.