Rate limits cap how many requests can hit the public authentication API per minute. They protect against abuse, smooth out bursts, and keep the platform stable for everyone. Each plan tier carries a different ceiling.
How limits are scoped
Section titled “How limits are scoped”Two scopes apply, in order:
- Per-tenant. Each tenant has its own requests-per-minute ceiling on the authentication endpoints (
/login,/registration,/token, etc.). Hitting the per-tenant cap returns 429 to the caller but doesn't affect other tenants. - Per-org aggregate. The sum across all your tenants' traffic is also capped. The aggregate cap is higher than any single tenant's cap; it primarily catches "many tenants suddenly very busy" scenarios.
Rate limits are smoothed over a sliding window — you can burst above the per-second average for a short period as long as the per-minute total stays under the cap.
Tier-level ceilings
Section titled “Tier-level ceilings”| Cap | Free | Starter | Pro | Enterprise |
|---|---|---|---|---|
| Per-tenant requests / minute | 100 | 1,000 | 10,000 | Custom |
| Org-wide aggregate / minute | 500 | 5,000 | 50,000 | Custom |
| Burst tolerance (window) | 30 sec | 30 sec | 60 sec | Custom |
"Custom" on Enterprise means the cap is provisioned per contract — typical Enterprise customers get capacity sized to their measured peak demand.
Endpoint-level differences
Section titled “Endpoint-level differences”Not every endpoint is rate-limited at the same level. The breakdown:
- Authentication endpoints (
/login,/registration,/token,/oauth2/*) — full rate-limit ceiling applies. These are the public-facing surfaces your end-users hit. - Webhook delivery endpoints (the URLs you receive from the platform) — separate ceiling, scaled to your subscription volume.
- Admin API (
/api/v1/applications,/api/v1/users, etc.) — lower ceiling than auth endpoints because admin actions are bursty + low-volume.
Rate limits don't apply to:
- Control plane API (the surface the cp-org-console uses). Authenticated as a member, gated by role, not rate-limited.
- Static asset fetches (logos, branding CSS, JS bundles). Served from a CDN-style cache, not rate-limited.
- Health probes at well-known endpoints. The platform's own infrastructure probes are exempt.
What callers see when they hit a limit
Section titled “What callers see when they hit a limit”The platform responds with HTTP 429 Too Many Requests plus three response headers:
Retry-After: <seconds>— how long the caller should wait before retrying.X-RateLimit-Limit: <number>— the cap that applies.X-RateLimit-Remaining: 0— explicitly zero, signalling the bucket is empty.
The body is a small JSON envelope describing which scope was hit (per-tenant vs. org-aggregate) and which endpoint family triggered the limit.
A well-behaved SDK or client handles 429 by reading Retry-After and waiting. The IntelliAuth React SDK does this automatically; for custom clients, implementing retry-with-backoff is the recommended pattern.
What ends up rate-limited (and what doesn't)
Section titled “What ends up rate-limited (and what doesn't)”Common scenarios:
- Brute-force login attempts. The per-tenant cap protects against credential stuffing. After the first ~hundred failed logins from any one source, the platform may also escalate to CAPTCHA challenges (Pro+).
- Bulk user imports. Admin API ceiling is lower; the right pattern is paginating + spacing the imports rather than firing thousands in a tight loop.
- Webhook receiver outages. If your webhook receiver returns 5xx, the platform retries with exponential backoff. Rate limits don't constrain webhook delivery to you.
What rate limits don't catch:
- Sustained high traffic from a single legitimate user. That's by design — a single power user should be able to use your product. Limits target volume, not behaviour pattern.
- Distributed credential stuffing. Spreading attempts across thousands of sources can stay under the per-tenant cap. Adaptive risk scoring (Pro+) is the right defence for this.
When to ask for more
Section titled “When to ask for more”If your tenants legitimately need more headroom than your tier provides, two paths:
- Upgrade your tier. Moving Starter → Pro is a clean 10x bump on auth-endpoint ceilings.
- Reach out for a custom limit. Enterprise tier customers can negotiate rate limits scaled to their measured peak. Contact your IntelliAuth account team.
What we don't do: bump limits ad-hoc on lower tiers. Limits are part of what each tier costs; bumping them off-contract would distort the pricing model.