Skip to main content
Rate limits protect the platform while staying far above normal usage. They apply identically to REST requests and MCP tool calls.

​
The buckets

Limits are token buckets: each bucket has a capacity (burst headroom) and a refill rate (sustained throughput). A request that finds its bucket empty gets 429. Expensive operations are the build-heavy endpoints: POST /v1/websiteSourceCode/head/check, POST /v1/websiteSourceCode/head/publish, POST /v1/websiteSourceCode/deployment/ensure, and POST /v1/websiteSourceCode/published/rollback-version. Everything else is standard. Additional IP-based abuse protections apply before authentication. Repeated authentication failures may be temporarily blocked. These protections apply to the REST API and MCP, not hosted website traffic.

​
Handling 429

A rate-limited response tells you exactly how long to wait:
Recommended client behavior:
  1. Honor Retry-After — sleep that many seconds, then retry the same request. Retrying a read or an idempotent write is always safe.
  2. Pace bulk work below the refill rate — for example, keep sustained traffic under 100 requests per second per key, and under 20 per second for publishes and exports.
  3. Queue, don’t fan out. If you operate many websites (an agency sweep, a bulk content update), run a worker pool with a global pace rather than firing per-site requests concurrently without bounds.
Publishing in a loop across many websites hits the expensive bucket first. Batch your edits per site, head/check once, publish once — not once per file.

​
Scope details

  • Per-key buckets are keyed to the key’s principal, so two keys in one organization have independent budgets.
  • MCP tool calls consume the same buckets as their REST equivalents — an agent and a script sharing one key share one budget. Give busy agents their own keys.
  • Limits are enforced before your handler runs; a 429 never partially applies an operation.