Rate limits
Limits are applied per key, so one busy integration cannot starve another key in the same workspace.
| Operation | Limit |
|---|---|
| Reads | 600 requests/minute |
| Writes | 120 requests/minute |
Both are per key, over a rolling minute, and both are the same on every plan that includes API access — Spectrum, Aurora and Cosmos get the same throughput. Higher tiers do not buy a higher limit today.
Writes are metered separately from reads, so a busy read integration cannot exhaust your ability to check attendees in.
Headers
Every response carries:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | The ceiling for this window |
X-RateLimit-Remaining | Requests left in the current window |
X-RateLimit-Reset | When the window resets (epoch milliseconds) |
X-Novex-API-Version | The API version that served the request |
A 429 additionally carries Retry-After, in seconds.
Backing off
When you get a 429, wait for Retry-After before retrying. Retrying
immediately will simply consume the next window too. If you are paginating a
large collection, prefer a larger limit (up to 100) over more requests.
If you need a higher ceiling for a specific integration, talk to us — the limit is a starting point, not a fixed property of the product.
During an incident on our side
If the store behind these limits becomes unreachable, we do not switch the limits off, and we do not refuse everything. Throughput falls back to a much tighter allowance until the store returns.
What you see is 429s at a volume you would not normally encounter, on requests
that would ordinarily be well inside your ceiling. Handle it the same way:
honour Retry-After and keep going. A door on the API keeps moving during one of
our incidents — slowly, rather than not at all.