Rate Limits

The Seller API enforces a rate limit per seller, per connected app: 10 requests per second. This limit is subject to change without notice.

Checking your usage

Every response counted against the limit — including a 429 — carries RateLimit headers (IETF draft-polli-ratelimit-headers-02) so you can see where you stand before you're rejected:

RateLimit-Limit: 10, 10;w=1
RateLimit-Remaining: 7
RateLimit-Reset: 1

RateLimit-Limit — the policy in effect: the limit, and the limit again with its window in seconds (w=1).
RateLimit-Remaining — an estimate of requests left in the current window. Treat it as a hint, not an exact count — don't assume a positive value guarantees your next request will succeed.
RateLimit-Reset — seconds until the window resets.

A request that isn't counted against the limit — a 401, or one that never reaches the limiter — has none of these headers.

What happens when you hit the limit

A request that exceeds the limit gets a 429 Too Many Requests response with a Retry-After header telling you how many seconds to wait (the same instant as RateLimit-Reset above):

HTTP/1.1 429 Too Many Requests
Retry-After: 1
RateLimit-Limit: 10, 10;w=1
RateLimit-Remaining: 0
RateLimit-Reset: 1

{
  "type": "rate-limited",
  "title": "Rate limited",
  "status": 429,
  "detail": "Rate limit exceeded"
}

See Errors for the full shape of this response.

What to do about it

Respect Retry-After. Wait at least that many seconds before retrying the same request.
Self-throttle using RateLimit-Remaining. Slow down as it approaches zero instead of waiting to be rejected — this is the proactive alternative to reacting to a 429 after the fact.
Back off exponentially on repeated 429s. If you're still being limited after waiting, double your wait time on each subsequent attempt (with jitter) rather than retrying on a fixed interval — this avoids synchronized retry storms across your own requests. For example: wait Retry-After seconds, then double that wait on each further 429 (1s, 2s, 4s, 8s, ...) up to some capped maximum, adding a small random jitter to each wait so retries from multiple clients don't line up. Most HTTP clients also have this built in — for example, urllib3.util.Retry or Tenacity in Python.
Spread out large syncs. If you're backfilling or syncing a large catalog, pace your requests under the limit instead of bursting.
Use batch endpoints where available, so one rate-limited request does the work of several:
- POST /inventory/set and POST /inventory/adjust each accept up to 10 variants per request.
- PATCH /products/{product_id}/variants updates up to 10 variants per request.
Cache what doesn't change often, such as product catalogs or dimension profiles, instead of re-fetching on every request.

Limit scope

The limit is per seller and per connected app — one high-volume integration won't exhaust the limit for a different app connected to the same seller, and different sellers using your app don't share a limit with each other.

Authentication

Webhooks