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

# Anthale API Rate Limits and Backoff

> Plan Anthale API throughput, rate-limit handling, backoff strategy, and capacity behavior for production enforcement requests and retries.

Anthale runs in-line with request flow, so rate-limit handling matters. This page covers Anthale's runtime API rate limits: what they control, which headers Anthale returns, and what happens on `429`.

## What Anthale limits

Anthale currently documents request rate limits for runtime API traffic. This is the limit that affects how many enforcement requests your application can send in a short window. Treat rate limits as part of your runtime design, not as an afterthought, because Anthale usually sits directly on the request path.

Anthale does not currently publish a public default rate-limit number. If Anthale publishes public rate-limit guidance in the future, this page will document it here.

## Response headers

Anthale returns rate-limit headers on API responses so your application can make backoff decisions with real numbers instead of guesswork.

| Header name           | Description                                                      |
| --------------------- | ---------------------------------------------------------------- |
| `ratelimit-limit`     | Maximum number of requests allowed within the current window     |
| `ratelimit-remaining` | Number of requests left in the current window                    |
| `ratelimit-reset`     | Number of seconds until the current window resets                |
| `retry-after`         | Number of seconds to wait before retrying after a `429` response |

Use these headers to drive queueing, concurrency caps, retry timing, and operational dashboards.

## What happens on `429`

When you exceed the current limit, Anthale returns `429 Too Many Requests`. Your integration should treat that as a temporary capacity signal, not as a malformed request or a policy problem.

The right handling pattern is straightforward:

* Honor `retry-after`.
* Retry with backoff and jitter.
* Smooth bursts instead of retrying everything at once.
* Separate user-facing and batch traffic when they have different latency requirements.

## Scope of this page

This page documents runtime API rate limits only. Anthale does not currently expose organization-level usage or billing in the dashboard, so treat this page as the source of truth for public runtime throughput behavior.

## Next steps

For retry semantics, read [Errors](/docs/api-reference/errors) or return to [API Reference](/docs/api-reference).