Rate limits

Each API key has a request budget per minute. The default is 120 requests per minute per key; your limit is returned by GET /ping as rate_limit_per_min, and we can raise it when you have a real need.

Headers

Every response carries your current budget:

Header	Meaning
RateLimit-Limit	Requests allowed per window
RateLimit-Remaining	Requests left in this window
RateLimit-Reset	Seconds until the window resets
RateLimit-Policy	The policy, e.g. 120;w=60

When you exceed the limit you receive 429 with error.code: "rate_limited" and a Retry-After header (seconds).

Staying under the limit

• Use webhooks, not polling. One webhook replaces hundreds of status polls.
• Cache menus and store lists for a few minutes. They change slowly.
• Poll tracking sparingly — once every 10–15 seconds while an order is out for delivery, and not at all otherwise.
• Back off on 429. Wait for Retry-After, then retry; add jitter if many workers share a key.
• Use one key per system. Limits are per key, so a staging load test cannot starve production.

async function call(url, init, tries = 5) {
  for (let i = 0; i < tries; i++) {
    const res = await fetch(url, init);
    if (res.status !== 429) return res;
    const wait = (Number(res.headers.get('Retry-After')) || 1) * 1000 + Math.random() * 250;
    await new Promise((r) => setTimeout(r, wait));
  }
  throw new Error('Still rate limited');
}

Limits protect restaurants and riders from runaway integrations as much as they protect our servers. If your launch will be bursty — a promotion, a campaign — tell us a week ahead and we will size your limit accordingly.