Skip to content

Rate limits

Every /api/v1 route is rate-limited using a sliding window, partitioned per authenticated caller (your credential’s client_id, as carried on your token) — falling back to the caller’s IP only for the anonymous token endpoint itself, where there’s no credential yet to key on.

Route Limit Window
POST /api/v1/auth/token 10 requests 60 seconds
Every other /api/v1/** route 300 requests 60 seconds

Both are sliding windows (evaluated over 4 sub-segments internally, not a hard reset every 60 seconds), so bursts right at a window boundary are smoothed rather than allowing exactly double the limit.

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json
{ "state": "RATE_LIMITED", "payload": null, "details": { "message": "Too many requests. Please try again later." } }

The error response never includes any detail about your remaining quota or window internals beyond Retry-After — the same generic-error posture applied to every other error on this API.

Respect the Retry-After header (seconds) rather than retrying immediately or on a fixed interval guess — it reflects exactly how long the window needs to free up capacity.

  • Token endpoint (10/min): if you follow the caching pattern in Authentication & tokens — refreshing only when your cached token is about to expire, roughly every ~4.5 minutes at most — you’ll use a small fraction of this limit under normal operation. If you’re hitting this limit, you almost certainly have a bug where you’re fetching a fresh token on every request instead of caching it.
  • Everything else (300/min): generous for typical order/cart/webhook-management traffic. If your integration does bulk catalog syncing (see Catalog delta sync), paginate at a reasonable page size (up to 100) rather than issuing many small-page requests back to back.
  • Build your HTTP client with a single retry-on-429-with-backoff policy at the transport layer (honoring Retry-After) rather than handling it ad hoc at every call site.