Rate limits & fair use

The numbers

Requests are counted per key. The work a request starts — new recordings and exports — is counted per account as well, so a second key buys a second request budget but not a second allowance of recordings. Every figure below is read from the running configuration, so this page cannot quote a number the API is not actually using.

GET /me reports the last two for your account, together with how much of today’s allowance is already spent. Read it rather than assuming the figures above apply to you.

The headers

Every response describes the window this request is closest to running out of — the per-minute window for most, and for a create or an export whichever of its own budgets is tighter. Not only the answers we refuse: a client that paces itself by these rarely meets a 429.

RateLimit-Limit: 120
RateLimit-Remaining: 114
RateLimit-Reset: 41
X-Request-Id: 0f2f5f6a-2c6c-4f4e-9d1e-5d8f2a1b3c4d

• RateLimit-Remaining — what is left in the window it describes.
• RateLimit-Reset — seconds until that window refills.
• Retry-After — sent only on a 429. Wait exactly that long.

Fair use

Beyond the request rate there is a ceiling on how much audio an account transcribes in a day, and on how long a single recording may be. This is the limit a heavy integration actually meets: it bounds the work, not the requests.

The daily allowance is not checked when a recording is created — how long it is is not known until it has been fetched. A recording over it is accepted and then fails with failure_reason: "quota_exceeded". The allowance resets daily; submit again then rather than straight away.

Concurrency

A plan allows a fixed number of recordings to be processing at once. Create one too many and the request answers 409 concurrency_limit — not 429, because nothing about waiting for a rate window helps. Wait for a recording to finish, then retry: a refused create does not spend the hourly or daily create budget. A fleet of workers racing for the last slot is handled correctly: exactly one of them wins.

Handling a 429

1. Read Retry-After and sleep for that many seconds. Do not retry sooner; an early retry spends another request and refills nothing.
2. Then retry with the same Idempotency-Key if it was a create — see idempotency.
3. If you are polling many recordings, lengthen the interval rather than the queue: see polling.

Raising a limit

These are the defaults, not a hard edge. If your integration genuinely needs more — a migration of an archive, a burst at the end of a month — tell us what shape the load is and we will raise the limits on your account rather than for everybody.