Last updated
Rate limits
Two things bound how much you can read: a per-workspace request rate, and the credits in the wallet. Hitting the first returns 429; running out of the second returns 402.
Request rate
Limits apply per workspace, across all of its keys, and come with the tier. The exact numbers are published on the pricing page once the plan matrix is final; the table below shows the shape. Subject to change
| Tier | Sustained | Burst | Concurrent streams |
|---|---|---|---|
| Free | cached reads only | — | 0 |
| Starter | low | short | 0 |
| Pro | medium | medium | a few |
| Scale / Agency | high | high | negotiated |
What a 429 looks like
A throttled request returns 429 with the standard error envelope and a Retry-After header in seconds. Wait at least that long before retrying; back off exponentially if you are throttled again.
HTTP/2 429Content-Type: application/jsonRetry-After: 12 {"code":"rate_limited","message":"Too many requests for this workspace. Retry after 12 seconds.","requestId":"req_…","retryable":true}Per-request quota headers (remaining requests in the current window) are planned. Subject to change
Credits
Independently of the request rate, every read is metered in credits from the workspace wallet. Cached reads are cheap; a request that queues a fresh observation costs more. When the wallet is empty, reads that need fresh data return 402 with code payment_required while cached boards stay readable.
resetAt instead of a fixed timer, and prefer webhooks over polling for LIVE events.