Rate Limiting

To ensure fair usage and platform stability, all API requests are rate
limited. Each API key gets its own quota: 100 requests per 60-second
window. Requests without an API key are limited by client IP address.

The limit is shared across all endpoints — every request you make counts
against the same bucket, regardless of which route it targets.

Rate limit headers

Every response includes headers describing your current quota:

Header	Description	Example
`X-RateLimit-Limit`	Maximum requests allowed in the current window	`10000`
`X-RateLimit-Remaining`	Requests remaining in the current window	`9942`
`X-RateLimit-Reset`	Unix timestamp (seconds) when the window resets	`1716643260`

Exceeding the limit

When the quota is exhausted, the API responds with 429 Too Many Requests.
The response includes a Retry-After header with the number of seconds to
wait before retrying:

{
  "status": 429,
  "title": "RESOURCE_EXHAUSTED",
  "detail": "Rate limit exceeded. Please retry later.",
  "code": "RESOURCE_EXHAUSTED"
}

Handling 429 responses

Respect Retry-After. Wait at least the indicated number of seconds
before retrying. Do not retry immediately in a tight loop.

Back off proactively. Watch X-RateLimit-Remaining and slow down
before hitting zero, rather than reacting to 429 responses.

Spread the load. If your workload is bursty, smooth it out across the
window instead of sending everything at the start.

Use one credential per system. Each API key has an independent quota,
so separate integrations should use separate credentials. This also keeps
the nonce sequence per process simple (see Signing a Request — Replay
protection).

Rate limit headers#

Exceeding the limit#

Handling 429 responses#

Rate limit headers

Exceeding the limit

Handling 429 responses