Skip to main content
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. 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 or return to API Reference.
Last modified on April 13, 2026