Rate Limits

Rate limits are applied per organization (based on the API key's team). Limits scale with your credit pack.

Per-plan limits

Burst limits prevent short spikes from overwhelming the system. Sustained limits cap your average throughput over a rolling 60-second window.

Some endpoint categories have tighter limits to protect resource-intensive services:

Enterprise plans have no endpoint-specific overrides — global limits apply.

Every response includes rate limit headers:

Header	Description
`X-RateLimit-Limit`	Maximum requests in the window
`X-RateLimit-Remaining`	Requests remaining in the window
`X-RateLimit-Reset`	Seconds until the window resets

When you exceed a rate limit, the API returns a 429 response with a Retry-After header:

{
  "statusCode": 429,
  "error": "Too Many Requests",
  "message": "Rate limit exceeded, please retry later",
  "retryAfter": 45
}

The Retry-After value (in seconds) tells you when you can safely retry.

Use batch endpoints for large datasets instead of making many single requests. A single bulk submit counts as one request.

Respect Retry-After — back off for the indicated duration before retrying.

Implement exponential backoff for transient failures.

Poll batch status at reasonable intervals (every 5–10 seconds) rather than in a tight loop.

Monitor your usage via the X-RateLimit-Remaining header to adjust throughput before hitting limits.

Upgrade your plan if you consistently hit limits — higher packs come with significantly higher rate limits.