Skip to main content

How limits work

Rate limits are enforced per API key, not per account. Each key can be configured with two independent windows: You set these when creating a key. Keys with no explicit limit inherit the platform defaults.

When a limit is exceeded

The API returns 429 Too Many Requests:

Handling 429 responses

Always implement retry logic for rate-limited requests. Use exponential backoff — wait progressively longer between retries:

Best practices

Spread bursty workloads. If you need to process a large batch of records, use a queue and throttle the dequeue rate to stay within your per-minute limit rather than firing everything at once. Create separate keys per workload. High-volume background jobs should use a different key from interactive user-facing flows. This prevents a batch job from consuming the limit that would block real-time requests. Monitor request volume. Log the response status of every API call. Alert on sustained 429 responses — it means your key limits need to be raised or your request rate needs to be reduced. Raise limits when needed. Update rateLimitPerMinute and rateLimitPerHour on a key via PATCH /v1/auth/keys/{id}/scopes (or recreate the key with higher limits) as your traffic grows.