Rate Limits & Quotas
What is limited
REST requests are throttled per authenticated user, or per client address when the call is anonymous. The MCP door is throttled per tenant. Authentication endpoints carry their own, separate ceiling.
The limits
| Surface | Ceiling |
|---|---|
| REST, anonymous | 30 requests/minute per address |
| REST, authenticated | 300 requests/minute per user |
REST, users with admin.access | 1,000 requests/minute per user |
| REST, authentication endpoints | 200 requests/minute |
/.well-known/* and /authorize | Exempt |
| MCP door | 600 requests/minute per tenant |
POST /api/mcp/api-keys/register/ | 5 requests/minute per address |
Ten failed authentication attempts within 60 seconds block the calling address for 300 seconds. Public forms and sign-up endpoints are limited separately, with their own, tighter ceilings.
What a limited response looks like
A limited REST or MCP call returns 429 with a Retry-After header giving the number of seconds to wait, and a body in the error envelope shape. The MCP door additionally returns X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset on every response, and RateLimit-* headers on a 429.
How to back off
Read Retry-After and wait at least that long before retrying. The official SDKs already do this: the Python and TypeScript clients retry 429, 502, 503, and 504 responses with backoff that honors Retry-After automatically — you don't need to implement retry logic yourself when calling through them.
Raising limits
Enterprise customers set request ceilings in the Order Form — see the SLA for tier-specific provisions.