Rate limits

Each API key has its own rate limit measured in requests per minute. The default is 120 requests per minute; your key's limit is set when it is created and shown in the vendor dashboard.

Exceeding the limit

When a key exceeds its limit, requests return 429 with the rate_limited error code:

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded. Retry after 12s.",
    "request_id": "req_8Kd2p1"
  }
}

When present, the Retry-After response header tells you how many seconds to wait before retrying.

Retry-After: 12

Staying under the limit

• Back off on 429. Wait for Retry-After (or use exponential backoff if it is absent), then retry.
• Use updated_since for polling so you fetch only what changed. See pagination.
• Batch with larger pages. Request limit=100 to move more data per call.
• Spread scheduled jobs rather than firing every request at the top of the minute.
• Split traffic across keys by workload, for example a separate key for a nightly reporting job, so bursty background work does not starve real-time booking calls.

Backoff example

async function withBackoff(makeRequest, max = 5) {
  for (let attempt = 0; attempt < max; attempt++) {
    const res = await makeRequest();
    if (res.status !== 429) return res;
    const retryAfter = Number(res.headers.get("Retry-After")) || 2 ** attempt;
    await new Promise((r) => setTimeout(r, retryAfter * 1000));
  }
  throw new Error("rate limited: exhausted retries");
}

Combine backoff with idempotency keys on writes so retries after a 429 never create duplicate reservations or orders.