Docs
Rate limits
Every plan gets a ceiling on how often its keys may call Validate or Issue, counted per minute.
Limits by plan
| Plan | Per key, per minute | Per IP, per minute |
|---|---|---|
| Free | 120 | 60 |
| Pro | 600 | 240 |
| Business | 2,400 | 600 |
| Enterprise | 12,000 | 2,400 |
Enterprise limits are custom; the numbers above are the platform default before a custom ceiling is agreed.
Two buckets
The key limit is checked first, because it is the ceiling you bought and the one worth knowing about. The IP limit exists underneath it as a guard against a leaked key, and a caller within their own plan will not see it in their headers, only in the response if it is what actually stopped the request.
Headers
X-RateLimit-Limit and X-RateLimit-Remaining are set on every answer, not only on a refusal, so a well-behaved client can pace itself before it is ever refused. On a 429, Retry-After names the wait in seconds, and it is echoed in the JSON body too as retryAfter.
Dormant workspaces
Rate limiting is a separate check from plan dormancy. A workspace whose owner is past a plan limit answers plan_limit (403) before rate limiting is even considered; see Errors. Rate limiting is fail-open: if the plan cannot be read, the request goes through rather than being refused over an unrelated database problem.