Rate Limit
RTZR STT OpenAPI controls usage by concurrency rather than time-based QPS. Policies differ for file mode and streaming mode. All limits apply per organization account.
File STT: Concurrency limit
File STT is constrained by a maximum concurrency limit (max number of files processed simultaneously). For example, with a concurrency limit of 10, up to 10 files can be processed at the same time. The 11th request will wait or fail depending on policy.
Response when exceeding the limit
When the limit is exceeded, the API returns HTTP 429 with:
{
"code": "A0002",
"msg": "Too many concurrent requests"
}
Streaming STT: Concurrent channel limit
Streaming STT is constrained by a maximum number of concurrent channels (sessions). For example, with a channel limit of 5, up to 5 concurrent connections can be maintained. The 6th will be rejected.
Limits by plan
Batch STT (file mode)
File STT concurrency limits vary by model.
| Plan | sommers | whisper |
|---|---|---|
| Free after signup | 10 | 2 |
| Paid (Basic) | 20 | 5 |
| Enterprise | Contact us | Contact us |
Streaming STT
| Plan | Concurrent channels |
|---|---|
| Free after signup | 5 |
| Paid (Basic) | 20 |
| Enterprise | Contact us |
For Enterprise, see the Pricing page or contact us to discuss an optimal limit.
Managing limits and best practices
Consider the following methods for reliable service operation.
Exponential backoff
If a request fails due to a limit (429) or transient network error, immediate retries may also fail. Use exponential backoff:
- After a failure, wait briefly (e.g., 1s) then retry.
- On each failure, double the wait time (e.g., 2s, 4s, 8s...).
- Stop after reaching max retries or max wait.
Client-side queue
If you must process many files, sending them all at once easily hits the limit. Implement a request queue to keep only up to the allowed concurrency in-flight; push the next file when one completes.