Rate limits
Default request ceilings and the response contract when a client exceeds them.
Current defaults
| Scope | Default | Applies to |
|---|---|---|
| Public read API | 120 requests/minute per client IP | Status, landing, summary and other public-read routes. |
| Authenticated file API | 300 requests/minute per client IP before entitlement/key checks | Subscriber file delivery. Additional abuse controls may also apply. |
| Checkout API | 30 requests/minute per client IP | Subscription checkout creation. |
| Customer portal API | 30 requests/minute per client IP | Billing portal session creation. |
| API-key management | 30 requests/minute per client IP | Key creation and revocation. |
| Stripe webhook | 120 requests/minute | Inbound billing webhook protection. |
429 response
When the active limit is exceeded the API returns HTTP 429 with code rate_limited. The response includes X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset and, when blocked, Retry-After.
Clients should stop retrying until Retry-After has elapsed or the reset timestamp has passed. Exponential backoff is recommended for automated ingestion.
Production fail-closed behavior
If the configured production rate-limit backend is unavailable or missing, protected pre-auth routes fail closed rather than silently running without request controls. The temporary failure response uses the same 429 contract and a 60-second retry interval.
Configuration and abuse
The defaults above may be overridden by production configuration without changing the HTTP response contract. If plan-specific or customer-specific limits are introduced, the applicable entitlement will be documented before it becomes customer-facing. Attempts to bypass rate limits or distribute traffic specifically to evade request controls violate the Terms of Service.