Rate limits
| Who | Limit |
|---|---|
| Each API key | 300 requests a minute |
| Each organisation — all its keys and dashboard sessions together | 600 requests a minute |
| Anything unauthenticated, per address | 300 requests a minute |
| The public capture routes, per address and collect link | 300 requests a minute |
Test mode is a separate organisation, with a separate budget.
Every response says where you stand, so a client can slow down before it is refused:
RateLimit-Limit: 300
RateLimit-Remaining: 287
RateLimit-Reset: 42
RateLimit-Reset is the seconds until the window starts again. An API key's response describes the
key's budget.
Over the limit, the answer is 429 with Retry-After in seconds:
HTTP/1.1 429 Too Many Requests
Retry-After: 18
Content-Type: application/problem+json
{ "type": "https://docs.akteora.com/errors/rate_limited", "title": "Too many attempts", "status": 429, "detail": "Too many attempts. Try again in 18 seconds.", "request_id": "01K5C3…" }
Wait that long, then carry on. For a burst of work, spread it out rather than retrying in a loop:
a queue that watches RateLimit-Remaining never meets a 429. Many small reads of the same list
are usually one paginated read, or a webhook instead of polling.
A run of unknown API keys from one address — someone guessing — is slowed down separately: after twenty, that address waits before its next attempt, and the wait grows while it continues.
The limits are generous for any integration we have seen. If yours needs more, tell us what it does.