Rate limits

• Limit: 100 requests per 60-second window.
• Scope: per API key. Mint additional keys if you need independent budgets for separate integrations.
• Window: fixed (aligned to the minute), not sliding. The counter resets at the top of every minute.

Every API response (successes and errors) carries three rate-limit headers:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1715760480

• X-RateLimit-Limit — the ceiling.
• X-RateLimit-Remaining — how many calls you have left in the current window.
• X-RateLimit-Reset — Unix timestamp (seconds) when the window rolls over.

The 101st request in a window returns 429 RATE_LIMITED with a Retry-After header telling you how many seconds remain in the window:

HTTP/1.1 429 Too Many Requests
Retry-After: 23
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1715760480

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Rate limit exceeded. Retry after 23s.",
    "requestId": "req_a1b2c3d4e5f6g7h8"
  }
}

1. Check X-RateLimit-Remaining on every successful response. If it drops below ~10, slow down preemptively.
2. On 429, sleep for the value of Retry-After and retry the exact same request. Do not exponentially escalate — the wait is bounded.
3. For background workers, queue + space requests rather than fanning out. One worker at 1 req/s never trips the limit; 100 parallel workers at 10 req/s each will.