> ## Documentation Index
> Fetch the complete documentation index at: https://docs.provisionapp.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> Per-key throttling, 429 responses, and Retry-After handling.

Each Public API key has a per-key throttle enforced by API Gateway. Requests that exceed
the limit are rejected with `429 Too Many Requests` **before** the handler runs, so your
integration sees the throttle even when the upstream service is healthy.

## Default limits

| Limit             | Default value                |
| ----------------- | ---------------------------- |
| Steady-state rate | 10 requests / second per key |
| Burst             | 20 requests                  |

The steady-state rate is what your integration can sustain indefinitely; the burst is the
short spike allowed on top of that. Both can be raised per key — email
[help@onevisionresources.com](mailto:help@onevisionresources.com) with the expected
RPS and a short description of the workload.

## What a throttled response looks like

```http theme={null}
HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json

{
  "message": "Too Many Requests"
}
```

The `Retry-After` value is the suggested number of seconds to wait before retrying. Build
your client to honour it; aggressive retries without backoff will keep you throttled.

## Recommendations

* Cache reads on your side when you can — `GET /v1/conversation/{id}` is the most common
  source of preventable load.
* Use exponential backoff with jitter on every `429` and on `503`.
* Spread out batch jobs; the per-second rate limit applies regardless of how the requests
  cluster.
* Treat the limits as a contract, not a soft target. If your integration grows past them,
  request an increase ahead of the change.