Rate limits - Crevio

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

{
  "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

Retry with exponential backoff and jitter

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.

Use webhooks instead of polling

Don’t poll a task or order for status changes in a tight loop. Subscribe to webhooks and let Crevio push the update to you.

Paginate, don't fan out

Walk list endpoints with cursor pagination (limit + starting_after) rather than firing many parallel requests.

Cache what rarely changes

Avoid re-fetching values that seldom move (product catalogs, account settings) on every request.

The @crevio/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

Errors

The full error model, including the 429 envelope.

Webhooks

Replace polling loops with pushed events.

Conventions

Cursor pagination and the rest of the API’s ground rules.

TypeScript SDK

Automatic retry and backoff out of the box.

​The limit

​What counts as a credential

​Response headers

​The 429 response

​Handling limits gracefully

​Next steps

Errors

Webhooks

Conventions

TypeScript SDK

The limit

What counts as a credential

Response headers

The 429 response

Handling limits gracefully

Next steps