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

# Rate limits

> Per-key limits, burst behavior, and how to handle 429s.

Every API key has a per-minute request budget. Default: 600 req/min.

## Response headers

Every 2xx response includes:

```
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 437
```

`Remaining` is how many more requests fit in the current minute
window.

## 429 responses

```http theme={null}
HTTP/1.1 429 Too Many Requests
Retry-After: 43
Content-Type: application/json

{"detail":"Rate limit exceeded"}
```

`Retry-After` is seconds until the next minute boundary. A
well-behaved client sleeps for that duration and retries.

Our SDKs do this automatically:

* Python: up to 3 automatic retries on 429, respecting `Retry-After`.
* TypeScript: same behavior.
* Override with `retry_on_429=False` if you'd rather handle it yourself.

## Fixed-window burst

The algorithm is a per-minute fixed-window counter — not a rolling
window. At the minute boundary, 2× the limit can pass in a single
second: the last second of minute A + the first second of minute B.

For most customers this doesn't matter. If you need strict smoothing,
implement a client-side token bucket on top.

## Tier options

| Tier         | rate\_limit\_per\_min | Typical use                                 |
| ------------ | --------------------- | ------------------------------------------- |
| Free / trial | 60                    | Development, small-scale testing            |
| Paid default | 600                   | Production CRM sync, warehouse pipelines    |
| Enterprise   | 6,000                 | High-volume campaigns, real-time dashboards |

Contact us for limits above 6,000/min. Most real workloads bat well
under 600/min when SDK pagination is used correctly.

## If Redis is down

We fail **open** during our own infrastructure outages — requests
that would hit the rate limiter get allowed through. This is a
deliberate tradeoff: a DoS control shouldn't block paying customers
when we're the ones broken. We monitor for the condition and fall
back to load-balancer rate limiting in emergencies.