Request limits

Cloud limits request rates and concurrent calls. These are the server defaults; operators can configure different values. They apply independently of spending budgets, tool resource budgets and plan allowances.

Rates and bursts

The rate is the sustained allowance. Burst is the most requests a full bucket admits together; allowance refills continuously at the configured rate. For example, 240 requests/minute with a burst of 30 refills four requests each second and admits up to 30 together after enough idle time.

Each row is a separate budget. A management mutation consumes both the management and mutation budgets. An MCP request consumes the management budget, and its call tool also consumes the shared execution budget. Public and authenticated requests still consume the outer IP budget. Invalid requests can consume allowance too.

Health checks have a separate IP allowance of 60/minute with a burst of five. Registered app origin lookups have an IP allowance of 120/minute with a burst of 30; exhaustion denies cross-origin access. The configured website origin needs no lookup.

Which account shares a quota

• A session uses the signed-in person's account, including when managing an organization.
• API keys use the account they belong to. Multiple keys on that account share its quota; creating a key does not add allowance.
• App calls use the app's owning account, including anonymous calls. Apps on that account share the execution quota with its other callers.
• REST and MCP tool calls use the same execution quota. Switching transport does not add allowance.
• Service webhooks use their destination service's budget, separate from tool execution. Standard and Stripe webhooks to that service share it.

Comped accounts remain subject to these limits.

Concurrency

Tool execution admits eight in-flight calls per calling account. Verified webhooks admit eight in-flight deliveries per destination service. These are separate limits. A slot is released when the request finishes or is cancelled; webhook slots remain held until the response body is consumed or dropped.

When concurrency is exhausted, reduce parallel calls and wait before retrying. Increasing the number of keys does not increase concurrency.

Node limits

The node running a service also limits outside calls, independently of Cloud admission: 600 calls per calendar minute per account, or per signed-in user of an app, and 60 per minute per anonymous visitor address within an app. These defaults are configurable on the node. A call must pass both Cloud and node limits.

Node rate refusals use a message asking the caller to retry in the next minute. They do not carry Cloud admission's structured code or Retry-After header.

Handling a refusal

Cloud admission refuses an HTTP request with 429, a Retry-After header in seconds, and a structured error. For example:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 2

{"error":{"code":"rate_limited","message":"request rate exceeded"}}

rate_limited means the request rate was exceeded. concurrency_limited means too many calls are in progress. Wait at least Retry-After before retrying, and add a small random delay when several workers share the quota. Retry only the refused operation; a timeout or lost response does not establish whether a mutation ran.

MCP tool execution returns JSON-RPC error -32029, with the same code and retry delay in error.data:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32029,
    "message": "too many calls in progress",
    "data": { "code": "concurrency_limited", "retry_after": 1 }
  }
}

MCP transport throttles return HTTP 429 before a tool runs. Endpoint-specific MCP OAuth throttles return HTTP 429 with Retry-After, a string error of temporarily_unavailable, and code: "rate_limited". An outer IP throttle uses the ordinary HTTP admission envelope.

Device sign-in also supplies a polling interval. Respect it even when the IP has allowance left. Polling sooner returns slow_down in error.code.

Other resource refusals can also use 429. Check the error body: E0019, for example, means the service owner's memory allowance is occupied. Waiting for request tokens alone does not resolve every 429.

Webhook bodies

Cloud accepts webhook bodies up to 2 MiB; a larger body receives 413. A webhook must still pass its signature and timestamp checks. Rate limits do not replace verification. See Webhooks.