Rate limits
On this page
Request limits are enforced per key, so one noisy integration cannot spend another's budget.
| Limit | Value | What it protects |
|---|---|---|
| Per API key | 600 requests per minute | Fairness between customers. Exceeding it returns 429. |
| Per IP address | 2,000 requests per minute | An abuse floor applied before authentication, generous enough for a shared corporate NAT. |
| Heavy operations | 3 at a time, shared across the service | Parsing, evaluation, summary, transcription, language detection and prompting run three at a time on capacity shared by all accounts. Beyond that, up to 12 requests wait their turn for at most 10 seconds; past that they get 503 with Retry-After: 30. |
| Request timeout | 300 seconds | The ceiling for any single call. Work that exceeds it returns 504. |
Typical latencies
Measured on production:
| Operation | Typical latency |
|---|---|
| Language detection | Under a second |
| Translation | Under a second |
| Interview summary (transcript) | 15 to 20 seconds |
| CV parsing | 40 to 90 seconds per document |
| Evaluation | 30 to 60 seconds |
Set your client timeout accordingly. A 30-second HTTP timeout will abandon calls that would have succeeded. Keep a request timeout above five minutes for the document operations.
Throughput
Because heavy work runs on shared capacity, throughput varies with load across the service. As an estimate, sustained throughput is roughly 2 to 4 CVs per minute. A queued request waits at most 10 seconds for a slot and then has 300 seconds to finish, so a long queue shows up as 503 and slow work as 504.
For backlogs and long recordings, use the async lane, which does not hold your connection open. If you need materially more throughput, or expect thousands of documents in a batch, tell us the shape of the workload and we will confirm the plan before you build.
Handling 429 and 503
Retry 429 and 503 with backoff. On 429, honour the Retry-After header when present. See Errors.
Updated