> ## Documentation index
> Fetch the complete documentation index at: https://developer.rhombus.com/llms.txt
> Use it to discover all available pages before exploring further.

# Rate Limits

> Understand Rhombus API rate limits and build resilient integrations that handle 429 throttled responses with exponential backoff and retry logic.

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

- [API keys](https://developer.rhombus.com/authentication/api-keys), including executable and chatbot keys
- [Partner credentials](https://developer.rhombus.com/partner-api-calls): partner keys, certificates and partner OAuth access tokens
- [OAuth access tokens](https://developer.rhombus.com/oauth-authentication)
- [Federated tokens](https://developer.rhombus.com/authentication/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 `429`s until the bucket refills.

Default rates apply to all organizations, and the same limits apply in both the US and EU [regions](https://developer.rhombus.com/api-regions) — they're enforced within your organization's region. To request a higher limit, contact [Rhombus support](mailto:support@rhombus.com).

## 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):

| Limit                                                                                                | Applies to                                                | Body                                                                                                                 |
| ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Organization rate limit                                                                              | Every REST request made with one of the credentials above | The JSON [error body](https://developer.rhombus.com/errors#the-response-envelope) with `"errorCode": "RATE_LIMITED"` |
| [Per-camera limits](https://developer.rhombus.com/rate-limits#per-camera-limits-on-clips-and-frames) | Creating clips and fetching exact frames, from any client | JSON with `"error": true` and an `errorMsg` naming the cameras                                                       |

```text Organization rate limit
HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json

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

```text Per-camera limit
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`.

> **Warning**: Do **not** immediately retry on a `429`. Repeated requests while rate limited continue to be rejected and do not reset your limit window.

## Per-camera limits on clips and frames

Clip creation ([`spliceV3`](https://developer.rhombus.com/api-reference/video-webservice/splice-v3) and the older `splice` and `spliceV2`) and exact frames ([`getExactFrameUri`](https://developer.rhombus.com/api-reference/video-webservice/get-exact-frame-uri), [`getExactFrameData`](https://developer.rhombus.com/api-reference/video-webservice/get-exact-frame-data) and [`getLiveImage`](https://developer.rhombus.com/api-reference/video-webservice/get-live-image)) 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](https://developer.rhombus.com/oauth-authentication).

## 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:

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

| Parameter    | Recommended value             |
| ------------ | ----------------------------- |
| Base delay   | 1 second                      |
| Max delay    | 60 seconds                    |
| Max attempts | About 5, within a time budget |

[Errors: retries and backoff](https://developer.rhombus.com/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](https://developer.rhombus.com/errors#retries-and-backoff) 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.

| Interval                | Seconds |
| ----------------------- | ------- |
| 1 minute                | 60      |
| 2 minutes               | 120     |
| **5 minutes (default)** | 300     |
| 10 minutes              | 600     |
| 20 minutes              | 1200    |
| 30 minutes              | 1800    |
| 1 hour                  | 3600    |

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.

> **Tip**: Alerts with **new identity information** — such as a different recognized face or license plate — bypass the backoff and are delivered immediately, even within the suppression window.