POST /boot and POST /chat to keep one visitor or one workspace from overwhelming the service. Limits apply at two levels: per visitor and per workspace. When a request crosses a limit, the worker rejects it with 429 and tells you when to retry.
The 429 response
A throttled request returns status429 with a JSON body and a Retry-After header (in seconds):
string
Which limit you hit, so you can tell visitor throttling apart from workspace throttling.
string
Always
rate_limit/exceeded for throttled requests.Retry-After header and wait at least that long before retrying. Some responses also carry the same value as a retryAfterSec field.
Burst windows report a fixed 60-second
Retry-After. Sustained per-visitor windows report the seconds remaining in the current window.Limits
A chat request can be checked against the visitor burst, workspace burst, and sustained per-visitor windows in turn. Requests that arrive without a valid visitor token fall back to the per-IP limit.
Back off cleanly
1
Honor Retry-After
On a
429, wait for the Retry-After interval before the next attempt. Do not retry immediately.2
Add exponential backoff with jitter
If retries keep failing, grow the delay on each attempt (for example 1s, 2s, 4s) and add a small random offset so concurrent clients do not retry in lockstep.
3
Cap retries and surface the limit
Stop after a few attempts rather than looping. The embed runtime already paces its own requests, so persistent
429s usually mean traffic is genuinely above the limit.Next steps
Errors
Every error namespace and status code, including the rate-limit envelope.
Authentication
How visitor sessions are minted and how programmatic API keys are scoped.
API reference
Request shapes and responses for the worker endpoints.