Rate limits

Overview

Requests are rate limited per organization and API key to ensure platform stability. Response headers communicate current window usage so clients can backoff proactively.

Aggressive polling of run status is a common cause of throttling; prefer webhooks or SDK wait helpers.

Step-by-step procedure

Key concepts

X-RateLimit-Limit

Maximum requests allowed in the current window.

X-RateLimit-Remaining

Requests remaining before throttling.

X-RateLimit-Reset

Unix timestamp when the window resets.

Best practices

• Implement exponential backoff with jitter on 429
• Cache list results where appropriate
• Use webhooks instead of polling run status aggressively

Budget traffic across the whole workflow

Measure traffic from scheduled jobs, interactive users, polling, retries, and parallel workers together. A limit shared across an account can be exhausted even when each worker appears to send little traffic.

Use the actual quota and retry behavior confirmed for your deployment. When Retry-After is supplied, respect it; otherwise follow the documented endpoint guidance. Introduce bounded backoff and jitter and inspect whether repeated writes could create duplicate work. Do not treat illustrative values in client examples as account entitlements.