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.
What you get back when you’re limited
Section titled “What you get back when you’re limited”HTTP/1.1 429 Too Many RequestsRetry-After: 12Content-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.
Practical guidance
Section titled “Practical guidance”- 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.