API Rate Limits
Every request to the API passes a process-wide limiter of 20 requests per second per client address. Sensitive operations carry a second budget on top of it, counted per organization or over a longer window. The two count different things: the process-wide limiter bounds throughput, and an operation budget bounds how often one caller may do one expensive thing.
Both apply at once. The process-wide budget is counted per client address; an operation budget is counted per organization on API key requests and per user on dashboard requests. A limit applies to the whole platform, so a request does not get a fresh budget by reaching a different server.
Request budgets
| Operation | Limit | Counted per |
|---|---|---|
| Every request | 20 per second | client address |
Organization creation (POST /v2/authentication/register) | 6 per hour | user |
| Wallet, wallet set, and token management | 10 per second | organization |
| Signing and transaction submission | 10 per second | organization |
Reads on API-key routes (GET) | 20 per second | organization |
Export and credential budgets
Three operations mint or retire something that cannot be taken back, so their budget counts how often, not how fast. Waiting does not earn a faster caller more of them.
| Operation | Limit | Counted per |
|---|---|---|
Private key export (POST /v2/customers/:id/export-private-keys, POST /v2/organizations/:organization/export-private-keys) | 5 per 24 hours | customer or organization |
API key creation (POST /v2/organizations/:organization/api-keys) | 10 per hour | organization |
| Member, role, invite, token, API key, webhook secret, and entity secret changes | 30 per hour | organization |
Response headers
Every response carries the state of the process-wide budget for the calling address:
| Header | Meaning |
|---|---|
RateLimit-Limit | Requests allowed in the current window. |
RateLimit-Remaining | Requests left in the current window. |
RateLimit-Reset | Seconds until the window resets. |
A refused request also carries Retry-After, in seconds, which says when that budget recovers.
429 response
A refused request returns 429 Too Many Requests with the standard error envelope:
Code
The message names the budget that refused the request, so a client can tell a throughput problem from a spent capability budget.
Handling a 429
- Read
Retry-Afterwhen it is present and wait that long. Otherwise readRateLimit-Reset. - Retry with exponential backoff. Do not retry in a tight loop.
- Use Webhooks instead of polling for transaction and wallet state changes.
- Send an
idempotencyKeyon every state-changing request. A retry after a refusal then runs once.
Scope
This page covers the API key surface. Endpoints outside it are not described here.
The security model describes where DDoS filtering sits, ahead of these budgets.