Rate Limits

REST API requests count against a rate limit when they're made with any of these credentials:

• API keys, including executable and chatbot keys
• Partner credentials: partner keys, certificates and partner OAuth access tokens
• OAuth access tokens
• Federated tokens

The limit is per organization: all of these credentials acting in your organization share one budget, with the same limits, so creating more credentials doesn't raise it. A partner credential's requests count against the client organization named in x-auth-org, or the partner organization when the header is absent.

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.

Bursts succeed instantly while the bucket has tokens. Once the bucket drains, sustained traffic above the refill rate returns 429s until the bucket refills.

Default rates apply to all organizations, and the same limits apply in both the US and EU regions — they're enforced within your organization's region. To request a higher limit, contact Rhombus support.

Throttled responses

Two kinds of limit answer with 429 Too Many Requests and a Retry-After header, the number of seconds to wait (at least 1):

HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json

{"error":true,"errorCode":"RATE_LIMITED","errorMsg":"…","status":429,"txid":"…", …}

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{"error":true,"errorMsg":"Clip creation is temporarily throttled for device(s) [AAAAAAAAAAAAAAAAAAAAAA]; retry after 12 second(s)"}

For the organization limit, Retry-After comes from your organization's refill rate. Branch on the status code or errorCode, and wait the seconds in Retry-After.

Per-camera limits on clips and frames

Clip creation (spliceV3 and the older splice and spliceV2) and exact frames (getExactFrameUri, getExactFrameData and getLiveImage) also have a limit per camera, separate from your organization's limit and shared by everything that uses that camera, including the console:

• Each camera allows a burst of requests, then a slower sustained rate.
• A rejection starts a waiting period, and requests during it are rejected too. Rejections after it ends make the next wait longer, so retrying early only delays you.
• A request that names several cameras is rejected as a whole if any of them is over its limit, and Retry-After is the longest wait.

To export or sample a lot of footage, spread requests across cameras and over time instead of sending them for one camera back to back.

OAuth client registration

Anonymous dynamic client registration (POST /oauth/register) has its own limits: 10 registrations per hour from one client IP address, and 100 per hour overall. Over either limit, registration answers 429 with Retry-After and an OAuth error body, where error is the string temporarily_unavailable. See Sign in with Rhombus.

Handling rate limits

1. 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.

2. Pause requests

   Stop sending requests for the duration specified in the header.

3. Retry your request

   After the wait period, retry the original request.

Retry strategy

Wait the Retry-After seconds on a 429, and back off exponentially with full jitter on temporary server errors:

delay = random(0, min(max_delay, base_delay × 2^attempt))

Errors: retries and backoff has a client wrapper in Python and JavaScript that applies these rules, and says which responses not to retry.

When to retry

Retry 429, 5xx responses and network failures; don't retry other 4xx responses or 200 responses with "error": true. Errors explains each case.

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.

Configure this per policy and per activity type. During the backoff window, duplicate alerts for the same device and activity type are suppressed server-side.