Rate limits
Per-route budgets and retry guidance
A reference table of the rate-limit budgets and the response headers we set. For client-side retry guidance, see POST /v1/ingest and the troubleshooting page on 429.
Budgets
| Route family | Budget | Reset window | Header |
|---|---|---|---|
POST /v1/ingest | 60 req / min per device | rolling 60 s | X-RateLimit-Device |
GET /v1/ingest/shelly | 60 req / min per device | rolling 60 s | X-RateLimit-Device |
POST /v1/ingest/lorawan | unlimited per webhook | — | — |
GET /v1/measurements | 120 req / min per account | rolling 60 s | X-RateLimit-Read |
GET /v1/measurements?export | 1 req / 5 min per account | rolling 5 min | X-RateLimit-Export |
POST /v1/reports | 4 req / min per account | rolling 60 s | X-RateLimit-Report |
POST /v1/auth/request | 10 req / min per IP | rolling 60 s | X-RateLimit-Auth |
* /v1/* (catch-all) | 600 req / min per account | rolling 60 s | X-RateLimit-Mgmt |
Response headers
Every response on a rate-limited route includes:
X-RateLimit-<family>— the budget for the family.X-RateLimit-Remaining— what is left in the current window.X-RateLimit-Reset— UNIX epoch seconds when the window resets.
On 429 Too Many Requests, the response additionally includes:
Retry-After— seconds until you can retry.
Limits are advisory, not punitive
The defaults above are sized so that a well-behaved device cannot trip them. If you trip them, the system is telling you something about your client — see the troubleshooting page.
If your operation is genuinely larger than the defaults — a 1 Hz power-meter sampling that genuinely needs 60 req / min — open a ticket. We raise budgets per-account on request; the limit exists to protect the pipeline, not to be a paywall.
We do not charge for higher rate limits. The Solo tier is priced for the entire usage profile; rate limits exist for safety.
Multi-tenant fairness
When the ingest path is contested (many tenants pushing simultaneously) the per-account budget is still the same, but latency can drift. We target ingest p99 < 500 ms. If you observe latency > 1 s sustained, file a ticket — it is a load problem on our side, not on your side.
Throttling philosophy
We throttle the client, not the storage. A burst of 1000 measurements in one second is fine if they arrive in one batched POST (under the 32-per-request cap, that means 32 batched POSTs in one second — still inside budget). It is not fine if those 1000 measurements arrive as 1000 individual POSTs — that is what the rate limit blocks.
This means the right strategy for high-rate sensors is batching at the device, not "buy a higher rate limit". The 32-per-request ingest endpoint is sized to make this easy.