Usage
Rate limits and balance
Per key there are request and token ceilings per minute; usage is covered by the organisation's prepaid balance.
Limits per key
The values follow the organisation's plan and are operational ceilings against bursts, not a feature tier.
| Plan | Requests / minute | Tokens / minute |
|---|---|---|
| Standard | 60 | 200,000 |
| Pro | 60 | 200,000 |
| Max | 300 | 1,000,000 |
Both surfaces count the same requests per minute per key. If you need more, spread load over several keys or talk to us.
Response headers
The App API sends three headers on every authenticated answer; on 429 additionally retry-after.
| Header | Meaning |
|---|---|
x-ratelimit-limit | Requests allowed in the current window. |
x-ratelimit-remaining | Requests left in the window (absent when the counter is momentarily unavailable). |
x-ratelimit-reset | Seconds until the next window starts (upper bound). |
retry-after | Only on 429: seconds before a retry makes sense. |
HTTP/1.1 429 Too Many Requests
retry-after: 60
x-ratelimit-limit: 60
x-ratelimit-remaining: 0
x-ratelimit-reset: 60
{ "error": { "code": "rate_limited", "message": "Too many requests. Retry after the indicated delay.", "request_id": "…" } }Balance
Usage through the API is deducted in euros from the organisation's prepaid balance — separate from the subscription and independent of the seats' usage allowance. There is no monthly reset.
How the developer API is billed is described on the pricing page.
Recommendations
- Back off exponentially on 429 and 503; honour retry-after.
- Stream long answers — the connection stays lean and timeouts become rarer.
- Request embeddings in batches rather than one by one.
- One key per application: limits and consumption stay attributable.