Skip to main content
The platform rate-limits requests to protect the backend from overload and abuse. Limits are enforced in Redis with a sliding window and are configurable per endpoint group — you can tune them without a code change.

​
How it works

  • Each protected endpoint belongs to a rate-limit group (for example create_run_async, kb_search, sandbox_create, tables_write, deployments_write, or default).
  • A group’s limit is a rule: N requests per time window (runs per delta_seconds).
  • The counter is keyed by the caller — the API key’s workspace for API-key endpoints, or the user for authenticated app endpoints — so one tenant’s traffic never consumes another’s budget.
  • When a caller exceeds the limit, the request is rejected with HTTP 429 and a Retry-After header telling the client how long to wait.
Limits are stored in the database and cached, so changes take effect without a redeploy. The in-code defaults are the fallback used if the stored config can’t be read.

​
Tuning the limits

Tenant admins configure the limits in the app under Settings → Platform → Rate limits. Each endpoint group shows its current allowance; adjust the number of requests and the window per group. Typical groups you’ll see:
Raise the groups your integration hammers (e.g. tables_query for a reporting job) rather than a blanket increase — the per-group split exists so one hot path can’t exhaust the whole budget.

​
Handling 429 in clients

Any client should treat a 429 as “back off and retry after the Retry-After interval.” The Python SDK already does this for you — it retries 429s with bounded exponential backoff that honors Retry-After, and raises RateLimitedError only after exhausting its retries. In other languages, read the Retry-After header and retry rather than hammering.
Rate limiting is one layer. Front the platform with your own WAF / gateway for IP-level protection and DDoS mitigation — see Inbound networking.