Rate limits
Organization request quotas, concurrency, polling, and retries.
Limits apply per organization and are shared by all API keys in that organization. The defaults below apply unless your organization has a custom limit.
| Operation | Default request limit | Counter |
|---|---|---|
| Create a generation | 20 requests per 60 seconds | Separate |
| Retrieve a generation | 20 requests per 60 seconds | Separate |
| Upload an asset | 20 requests per 60 seconds | Separate |
| Retrieve or delete an asset | 20 requests per 60 seconds combined | Shared |
Requests above the limit return HTTP 429, with code rate_limit_exceeded for generation endpoints or 00009 for asset endpoints.
Concurrency and polling
By default, an organization can run up to 5 generations concurrently. Concurrency and request rate are separate limits. Accepted generations wait for capacity when the concurrency limit is reached.
Poll a single generation about every 5 seconds. When polling multiple generations, increase the interval to keep the combined request rate within your limit. Stop polling when the status is succeeded, failed, or canceled.
Retries
- Retrieval requests: for network errors,
429,500, or503, use capped exponential backoff with jitter, such as approximately 5, 10, 20, and 30 seconds. Set an overall timeout. - Invalid input or access errors: correct the input, API key, or permissions before retrying.
- Generation creation: requests are not guaranteed to be idempotent. Do not automatically resend after a timeout, a lost response, or a
5xxresponse; this may create duplicate generations. If you have a generation ID ordetails.generation_id, resume polling. Without an ID, the retrieval endpoint cannot locate that request. - Asset uploads: repeated uploads may create separate assets. Save each returned asset ID.
A client-side polling timeout does not cancel a generation. Use the saved ID to retrieve its status later.
Higher limits
Contact us if you need higher request limits or more concurrent generations.