Skip to content
PlatformRate limits

Rate limits

Two independent limits protect the platform: a request-rate limit (requests per minute) and a concurrency cap (simultaneous in-flight renders). Both are per plan and counted per API key.

Limits by plan

PlanRequests / minMax concurrentMax timeout
sandbox10115s
hobby60330s
growth2001045s
business5002560s

Rate-limit headers

Every render response carries your current budget. When you exceed the per-minute limit you get 429 RATE_LIMIT_EXCEEDED plus a Retry-After.

response headers
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 188
Retry-After: 41

Concurrency

Exceeding your concurrent-render cap returns 429 RATE_LIMIT_EXCEEDED with details.retry_after_ms. This stops one key from monopolizing the render pool; retry after the suggested delay.

Handling 429s

Back off exponentially

On a 429, wait Retry-After seconds (or details.retry_after_ms) and retry with jitter. For sustained high throughput, switch to async renders or upgrade your plan for a higher ceiling.

Fail-open

Rate limiting degrades gracefully: if the limiter backend is unavailable, requests are allowed through rather than blocked. You won't be rate-limited by an outage on our side.