# Rate limits

Requests are limited per client IP per minute, by tier. Defaults:

| Tier | Routes | Default limit per minute |
|---|---|---|
| `cheap` | fee, ledger, health, network health, health history | 120 |
| `expensive` | orderbook, slippage, amm, account (summary, lines, transactions), token, payment-readiness, paths | 30 |
| `pro` | everything under `/v1/pro` | 120 |
| `mcp` | every request to `/mcp` | 120 |

The MCP tools for these routes also draw from the `expensive` tier, so MCP is not a way around it. Limits are best-effort counters and can differ per deployment.

## When you are limited

The response is 429 with `application/problem+json`, a `Retry-After` header and a `retry_after_seconds` field. Wait that long before retrying. See [rate-limited](https://api.criptonlabs.com/errors/rate-limited.md).

## RateLimit headers (advisory)

When the service knows the counters it adds `RateLimit-Limit`, `RateLimit-Remaining` and `RateLimit-Reset` (seconds until the window resets) to `/v1/*` responses, including 429. They are advisory and per instance, so the real limit can be looser than they suggest, and they may be absent. Always honor `Retry-After` on a 429.

## Staying under the limit

- Respect the cache TTL on each endpoint page; faster polling returns identical data.
- Prefer one slippage call over many order book calls: the book is cached and the amount is not part of the cache key.
- Back off on 429 and 503 instead of retrying immediately.