Rate limits
Each request counts against one or more limits on your account. Exceed a limit and the request returns 429 Too Many Requests.
The default limit
Every account has a global limit of 60 requests per minute, applied across all endpoints. Some heavier endpoints (full-inventory exports, bulk imports) carry their own additional, slower limit on top of the global one. The reference page for those endpoints lists the extra limit alongside the operation.
Limits apply per account, not per key. Two keys on the same account share the same 60-per-minute pool. To get more headroom, request a higher limit (see below) — minting more keys won't help.
Response headers
Every successful response carries:
| Header | Meaning |
|---|---|
X-RateLimit-Limit |
The applicable limit. |
X-RateLimit-Remaining |
Requests left before the limit resets. |
X-RateLimit-Reset |
Epoch seconds when the limit window ends. |
When more than one limit applies (a global limit plus an endpoint-specific one), the headers reflect whichever is closest to its ceiling — i.e. the constraint that's actually pressing.
Hitting the limit
Over the limit, the response is 429:
HTTP/1.1 429 Too Many Requests
Retry-After: 27
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1745672100
Content-Type: application/json
{
"code": "TOO_MANY_REQUESTS",
"status": 429,
"message": "Rate limit exceeded",
"data": {
"bucket": "global",
"limit": 60,
"retryAfter": 27
}
}
The Retry-After header (delta seconds) is the canonical wait-and-retry signal — most HTTP client libraries honour it natively. The same value also appears in data.retryAfter for clients that prefer reading the body. data.bucket identifies which limit was exceeded (global for the per-account limit, or the specific endpoint-bucket name for stricter limits).
Backoff
After a 429, sleep Retry-After seconds before retrying the same request. For background jobs that drive a lot of writes, pace your concurrency so the steady-state stays below the limit instead of bursting and absorbing 429s. A 1 request/second cap on a single worker is a safe pattern under the default 60-per-minute ceiling.
Requesting a higher limit
The default tier covers most integrations. For high-volume seller accounts, marketplace aggregators, or other use cases where 60 per minute is too restrictive, contact support with:
- Your username or the email on your account.
- A short description of the integration and expected steady-state RPS.
- Which endpoints drive most of your traffic.
Limit increases are provisioned per account, so they apply to every key on that account.