Nusomi enforces rate limits at two layers: per API key (to protect against runaway scripts) and per workspace (to protect aggregate cost).Documentation Index
Fetch the complete documentation index at: https://docs.nusomi.com/llms.txt
Use this file to discover all available pages before exploring further.
Default limits
| Surface | Per key | Per workspace |
|---|---|---|
POST /v1/sessions (create) | 30 / s | 200 / s |
POST /v1/sessions/:id/events (emit) | 1000 / s | 5000 / s |
POST /v1/sessions/:id/frames (upload) | 200 / s | 1000 / s |
GET reads (sessions, events, frames) | 200 / s | 2000 / s |
Streaming /events/stream | 50 concurrent | 500 concurrent |
POST /v1/exports | 5 / minute | 30 / minute |
POST /v1/replays (live sandbox) | 10 / minute | 50 / minute |
Headers
Every response includes:Retry-After is in seconds.
Burst behavior
Limits are token-bucket. The bucket size is 2× the per-second rate, and refills continuously. So a200/s limit lets you burst 400 requests then drain — useful for catch-up after a network hiccup.
Request batching
A few endpoints accept batches to reduce QPS pressure:| Endpoint | Max batch |
|---|---|
POST /v1/sessions/:id/events | 100 events |
POST /v1/sessions/:id/frames | 50 frames |
Quotas vs. rate limits
Rate limits are about request rate. Quotas are about absolute volume per billing period. Hitting a quota returnsquota_exceeded (also 429). Quota state:
null means unlimited (typical on enterprise tiers).
Asking for a higher limit
Emailsupport@nusomi.com with your workspace ID, the surface you’re hitting limits on, and a rough QPS estimate. Same-day turnaround for read-heavy increases.