All API requests authenticated via API key or OAuth token are subject to rate limiting. Limits are enforced per organization — every API key and OAuth token issued to your organization shares one rate-limit budget. Creating additional credentials does not raise your limit.Documentation Index
Fetch the complete documentation index at: https://api-docs.rhombus.community/llms.txt
Use this file to discover all available pages before exploring further.
| Authentication method | Header | Applies to |
|---|---|---|
| API key | x-auth-apikey | Developer and Partner Developer accounts |
| OAuth token | x-auth-access-token | OAuth-authorized applications |
How limits work
Rhombus uses a token bucket algorithm. Two values govern your throughput:- A sustained refill rate (requests per second) — your steady-state ceiling.
- A burst capacity, roughly 10× the refill rate by default — headroom that absorbs short spikes.
429s until the bucket refills.
Default rates apply to all organizations. To request a higher limit, contact Rhombus support.
Throttled responses
When your request is rate limited, the API returns a429 status with a Retry-After header:
HTTP 429 response
| Detail | Value |
|---|---|
| Status code | 429 |
Retry-After header | Seconds to wait before retrying. Computed from your organization’s refill rate; always at least 1 second. |
| Body | Too many api requests. Enhance your calm. |
Handling rate limits
Read the Retry-After header
The
Retry-After header tells you exactly how many seconds to wait, computed from your organization’s refill rate. Always prefer this value over hardcoded delays.Retry strategy
Use exponential backoff with jitter for the most resilient integration:Backoff formula
| Parameter | Recommended value |
|---|---|
| Base delay | 1 second |
| Max delay | 60 seconds |
| Max retry attempts | 5–10 |
| Jitter | Random 0–1 second |
- Python
- JavaScript
- cURL
retry_with_backoff.py
When to retry
| Response | Action |
|---|---|
200–299 | Success — no retry needed |
429 | Wait for Retry-After seconds, then retry |
5xx | Transient server error — retry with exponential backoff |
4xx (not 429) | Client error — fix the request, do not retry |
The rate limiting system is fail-open. If the rate-limit service or its backing store is unavailable, your request is allowed through. Do not rely on this behavior — always design your integration to respect limits.
What changed
Recent rate-limiter improvements are now live:
- Limits are now pooled across all of an organization’s credentials. Distributing traffic across multiple API keys no longer increases throughput.
- Short bursts above your sustained rate are now allowed.
Retry-Afterreflects the true wait time computed from your refill rate, instead of a fixed 60 seconds.
Alert notification throttling
Alert notifications (distinct from API rate limits) have a configurable minimum interval between consecutive alerts of the same type for a given device. This prevents alert fatigue from high-frequency events like motion detection.| Interval | Seconds |
|---|---|
| 1 minute | 60 |
| 2 minutes | 120 |
| 5 minutes (default) | 300 |
| 10 minutes | 600 |
| 20 minutes | 1200 |
| 30 minutes | 1800 |
| 1 hour | 3600 |