Rate limits
Three buckets — browser, programmatic, and per-key — sized by plan, so a script can never starve your own dashboard.
Last updated on
Every request counts against one or two of three buckets, keyed by workspace and checked per minute:
| Bucket | Who it covers | Why it is separate |
|---|---|---|
Programmatic (requestsPerMinute) | API keys, the CLI, MCP | The budget for everything that isn't a browser session. |
Per key (requestsPerMinutePerKey) | One API key | Tighter than the programmatic bucket, so one leaked or looping key cannot spend the whole workspace's budget. |
Browser (webRequestsPerMinute) | Dashboard sessions | Sized much higher, because a page load costs many requests and the browser must never be throttled by a script hitting the same workspace over the API. |
Both buckets that apply to a request are checked, and the tighter refusal is reported first.
Limits by plan
| Plan | Programmatic / min | Per key / min | Browser / min |
|---|---|---|---|
| Free (no subscription) | 20 | 10 | 120 |
| Hobby | 120 | 60 | 300 |
| Pro | 600 | 300 | 600 |
| Business | 2,000 | 1,000 | 1,200 |
These are per-workspace ceilings, not per-request-type: every operation you call, GET or POST, spends one unit from the same bucket.
What a refusal looks like
{
"code": "RATE_LIMITED",
"message": "Too many requests. Retry in 42s.",
"data": { "retryAfter": 42 }
}HTTP status 429. Back off for data.retryAfter seconds before retrying. MCP returns the same refusal shaped as a JSON-RPC error, with a Retry-After header.
API key cap
A workspace can hold at most 25 live API keys, across every member. Minting a 26th is refused with a message naming the limit — revoke one you no longer use. This is a flat cap on every plan: a key grants no extra capacity beyond the workspace's own limits, so the cap bounds convenience, not value.
If a Redis outage disables the limiter
Rate limiting fails open: if the limiter's storage is unreachable, the request is allowed rather than blocked. This is a deliberate trade-off — an outage in a safety mechanism should not become an outage in the product — not a reason to expect the limits above to be strictly enforced at every instant.