> ## Documentation Index
> Fetch the complete documentation index at: https://docs.get-exo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limit exceeded

> The caller's token bucket for this family of operations is empty.

This page is the resolution target of the RFC 9457 `type` URI on every `rate_limit_exceeded` problem body: `https://docs.get-exo.com/errors/rate_limit_exceeded`.

**HTTP status: `429` Too Many Requests**.

```json theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
{
  "type": "https://docs.get-exo.com/errors/rate_limit_exceeded",
  "title": "Rate limit exceeded",
  "status": 429,
  "detail": "Rate limit exceeded for writes operations: 120 requests per minute. Retry in 3 seconds.",
  "code": "rate_limit_exceeded",
  "requestId": "req_9f2c41ab7d0e5c18",
  "suggestedAction": "Wait for the Retry-After interval before retrying, and spread requests more evenly over time.",
  "documentationUrl": "https://docs.get-exo.com/platform/rate-limits"
}
```

## Why it happens

Limits are per credential and per family, so a burst of writes cannot drain your read allowance. The families are reads, writes, ingest, sessions, search and exports, each with its own burst capacity and sustained per-minute refill.

The 429 response carries the same `RateLimit` and `RateLimit-Policy` headers a successful response does, plus `Retry-After` in whole seconds.

## How to fix it

* Honour `Retry-After`. It is computed from your actual bucket state, not a fixed backoff.
* Read `RateLimit` on successful responses and slow down before you hit the wall: `r` is your remaining tokens and `t` is seconds until the bucket is full again.
* Spread work over time rather than retrying immediately. Buckets refill continuously.

## Related

* [`too_many_streams`](/errors/too_many_streams)
* [`service_degraded`](/errors/service_degraded)
* [Errors](/platform/errors) for the envelope and the full catalogue