Rate limits

Per-key per-minute and per-day request caps.

Defaults

New keys default to 60 requests per minute and 10,000 per day. Raising the cap on a specific key is not self-serve today; please contact our team at [email protected] if you need a different ceiling on one of yours.

Response headers

Every request, success or failure, comes back with the current rate-limit state in headers. Watch them in your client and back off as you approach zero.

Success with headroom

text

HTTP/1.1 200 OK
X-RateLimit-Remaining-RPM: 47
X-RateLimit-Remaining-Daily: 9842
X-Request-ID: 5b7e9c2a-4f31-...

When you hit the limit

When you exceed either the per-minute or per-day cap the server returns 429 Too Many Requests with Retry-After (seconds). Honor it and implement exponential backoff for repeated 429s.

Tip

Need more throughput? Split traffic across multiple keys (each gets its own bucket) or contact our team at [email protected] so we can raise the cap on yours. Per-key limits are not self-serve in the dashboard yet. Either way, never hard-loop on a 429: back off with jitter on retries.

429 response

text

HTTP/1.1 429 Too Many Requests
X-RateLimit-Remaining-RPM: 0
X-RateLimit-Remaining-Daily: 9842
Retry-After: 60

{
  "error": "Rate limit exceeded",
  "code": "rate_limited",
  "request_id": "0cf409f7-382a-4c24-be9f-ae1192c38619",
  "detail": "Rate limit exceeded"
}

Streaming and long requests

A streaming TTS request or a long-running transcription job counts as a single request against your RPM. The audio bytes / characters consumed are tracked separately under your credit usage and don't affect rate-limit headers.