Rate Limits

The API enforces rate limits to ensure fair usage. Limits vary by tier.

Limits by Tier

Limit	Premium	Business
Requests per minute	60	200
Daily export creations	100	Unlimited
Concurrent exports	1	5
Max queued exports	3	5
Export creations per 5-minute window	20	60

All limits are scoped per API token. A user holding multiple API tokens gets independent budgets per token.

💡

Bulk uploads don't count

URLs submitted via /v1/batch-export are excluded from the per-5-minute window. A 25- or 100-URL bulk submission counts as one API call against the budget, not 25 or 100. Bulk has its own per-batch URL ceiling (Premium 25, Business 100).

Rate Limit Headers

Rate-limited responses return HTTP 429 with:

json

{
  "status_code": 429,
  "error_code": "RATE_LIMIT_EXCEEDED",
  "seconds_to_wait": 42,
  "detail": "Rate limit exceeded. You have created 60 exports in the last 5 minutes (limit: 60). Retry in 42 seconds."
}

Plus these response headers:

Header	Meaning
`X-RateLimit-Limit`	The cap (e.g. `60`)
`X-RateLimit-Remaining`	Slots left in the current window
`X-RateLimit-Retry-After`	Unix timestamp when the next slot opens
`X-RateLimit-Window`	Window length (e.g. `5 minutes`)

The seconds_to_wait / X-RateLimit-Retry-After value reflects when the oldest in-window export rolls out — not the full 5-minute window. If you hit 429 because you submitted 60 exports in the first minute of the window, you'll be told to retry in ~4 minutes; if you hit it because of steady traffic, the wait is usually 30–120 seconds.

Retry Strategy

💡

Recommended approach

Use the seconds_to_wait value from 429 responses to implement backoff. For polling job status, use 5–10 second intervals instead of continuous polling.

Check the seconds_to_wait field in 429 responses (or X-RateLimit-Retry-After)
Wait the specified duration before retrying — it's accurate, not a fixed window
Use exponential backoff as a fallback strategy
Consider using webhooks instead of polling to avoid rate limits