Rate limits
The API limits how many requests one organisation can make per second, and how many one IP can make against the public endpoints. The limits protect every tenant from a noisy neighbour; counters live in memory on the one core instance.
The limits
| Surface | Limit |
|---|---|
| Reads, per organisation | 50 per second |
| Writes, per organisation | 10 per second |
Public endpoints (/v1/public/*), per IP | 10 per second |
Sign-up (POST /v1/signup), per IP | 5 per hour |
A write is any POST, PUT, PATCH or DELETE; a read is everything else. Unauthenticated requests to non-public endpoints are not limited.
The 429 response
Over a limit, the API answers 429 with the usual problem document and code rate_limited:
{
"type": "https://api.issuer.example/problems/rate_limited",
"title": "Too Many Requests",
"status": 429,
"detail": "Rate limit exceeded, retry in 1 second",
"code": "rate_limited",
"request_id": "req_9c40..."
}
The response carries the draft-spec headers:
| Header | Meaning |
|---|---|
ratelimit-limit | The ceiling for the current window. |
ratelimit-remaining | How many requests are left in it. |
ratelimit-reset | Seconds until the window resets. |
Retry-After | Seconds to wait before the next attempt. |
Honour Retry-After and back off; the SDK's retryingFetch reads it for you, as described in Idempotency and retries. Retry a write with the same Idempotency-Key so a request that did land is not repeated.
A burst that exceeds 10 writes per second is throttled per organisation, not per API key, so several workers sharing an organisation share one budget. Spread a batch over time, or size the workers to the budget, rather than retrying tightly and adding to the pressure.