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 and summarisation run three at a time on capacity shared by all accounts. Beyond that, requests wait their turn; they are never rejected for concurrency alone. |
| 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 still has to finish inside the 300-second timeout, so a long queue shows up as slower responses and then 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