Rate limits

Aeses enforces per-key rate limits to protect the platform and ensure fair use. Limits apply independently to test and live keys.

Default limits

| Plan | Read (GET) | Write (POST/DELETE) | | ---------- | ------------ | ----------------------- | | Standard | 100 req/s | 25 req/s | | Scale | 500 req/s | 100 req/s | | Enterprise | Custom | Custom |

Bursts of up to 2× the steady-state limit are tolerated for short windows.

Inspecting your limits

Every response includes these headers:

| Header | Description | | ----------------------- | ------------------------------------------------------------ | | X-RateLimit-Limit | Maximum requests permitted in the current window. | | X-RateLimit-Remaining | Requests remaining in the current window. | | X-RateLimit-Reset | Unix timestamp (seconds) when the window resets. | | Retry-After | Present on 429 responses. Seconds to wait before retrying. |

Hitting the limit

When you exceed the limit, Aeses responds with 429 rate_limit_error:

{
"error": {
  "type": "rate_limit_error",
  "code": "rate_limited",
  "message": "Too many requests. Retry after 1.2 seconds.",
  "request_id": "req_01HXYZ..."
}
}

The response includes a Retry-After header. Sleep for at least that duration before retrying. Combine with exponential backoff to avoid thundering-herd retries on a transient spike.

Designing around limits

• Batch where possible. Use the list endpoints with limit=100 instead of polling individual resources.
• Subscribe, don't poll. Listen for webhooks instead of polling deposit/withdrawal status.
• Cache reads. Balance and account data does not change often — cache results for at least 10 seconds.
• Separate keys per workload. Use different API keys for synchronous user-facing traffic and background reconciliation so a heavy batch job cannot starve checkout.

If you regularly hit your limit, request an increase from Dashboard → Developers → Plan limits.