> ## Documentation Index
> Fetch the complete documentation index at: https://crevio.co/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Rate limits
> How Crevio throttles API requests — the per-credential limit, the X-RateLimit-* headers on every response, and how to back off cleanly on a 429.
**Every Crevio API request is rate limited, and every response tells you exactly where you stand.** Read the `X-RateLimit-*` headers to pace yourself, and back off on a `429` instead of hammering.
## The limit
Crevio allows **600 requests per 60-second window** per credential. That's an average of 10 requests per second, with room to burst within the window.
| | |
| ------------------ | ------------------------------------- |
| **Limit** | 600 requests |
| **Window** | 60 seconds (fixed) |
| **Scope** | Per credential — see below |
| **Over the limit** | `429` with code `rate_limit_exceeded` |
The window is **fixed**, not rolling: the counter resets to zero at the moment given by `X-RateLimit-Reset`, not 60 seconds after each individual request.
The limit is uniform across **all** `https://api.crevio.co/v1` endpoints — reads and writes draw from the same counter. There are no per-endpoint or per-plan tiers.
## What counts as a credential
The counter is keyed to whoever is making the call, so one integration can never exhaust another's budget:
* **API token** — requests authenticated with `Authorization: Bearer YOUR_API_TOKEN` are counted per token. Issue separate tokens for separate workloads and they get separate budgets.
* **IP address** — OAuth-session and unauthenticated requests fall back to per-IP counting.
## Response headers
Every response — success or failure — carries your current standing. Read these instead of guessing.
| Header | Meaning |
| ----------------------- | ----------------------------------------------------------------------------------------------- |
| `X-RateLimit-Limit` | Maximum requests allowed in the window (`600`). |
| `X-RateLimit-Remaining` | Requests left in the current window. |
| `X-RateLimit-Reset` | UTC epoch seconds (Unix timestamp) when the window resets and `Remaining` returns to the limit. |
```http theme={null}
HTTP/1.1 200 OK
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 594
X-RateLimit-Reset: 1735689600
```
When `X-RateLimit-Remaining` is getting low, compute the wait from `X-RateLimit-Reset`: `wait_seconds = X-RateLimit-Reset - now`. Pause until then rather than retrying into a wall.
## The 429 response
Exceed the limit and the request is rejected with HTTP `429` and the standard [error envelope](/developer/guides/errors):
```json theme={null}
{
"error": {
"type": "invalid_request_error",
"code": "rate_limit_exceeded",
"message": "Too many requests. Please retry later."
}
}
```
The `X-RateLimit-*` headers are included on the `429` too, so `X-RateLimit-Reset` tells you exactly when to try again.
## Handling limits gracefully
On a `429`, wait, then retry — doubling the delay each attempt and adding a small random jitter so concurrent clients don't retry in lockstep. Prefer the `X-RateLimit-Reset` timing when it's available.
Don't poll a task or order for status changes in a tight loop. Subscribe to [webhooks](/developer/guides/webhooks) and let Crevio push the update to you.
Walk list endpoints with cursor [pagination](/developer/guides/conventions#pagination) (`limit` + `starting_after`) rather than firing many parallel requests.
Avoid re-fetching values that seldom move (product catalogs, account settings) on every request.
The [`@crevio/sdk`](/developer/guides/sdk) already retries `429` (and transient `5xx`) responses with exponential backoff for you — most integrations on the SDK never need to handle this by hand.
## Next steps
The full error model, including the `429` envelope.
Replace polling loops with pushed events.
Cursor pagination and the rest of the API's ground rules.
Automatic retry and backoff out of the box.