There are no rate-limit plans or tiers on the Seller API.
Production keys: not rate limited#
A production key must carry an IP allowlist, and those addresses are synced into the platform's edge bypass. That allowlist is the gate: the API itself does not count or cap requests from a production key, and it never answers 429 to one. Capacity is a platform concern, not a per-seller entitlement, so there is nothing to negotiate or upgrade.
Traffic that trips the edge network's own abuse protection still receives an HTML 403
challenge before it reaches the API — see Error playbook. Keep bursts
sane, send If-None-Match on catalog reads, and register every egress IP.
Sandbox keys: one flat abuse cap#
Sandbox keys all route to the shared sandbox catalog, which anyone can obtain a key for, so they keep a single protective cap. It is identical for every company and is not a plan.
| Kind | Per minute (sliding window) |
|---|---|
| write (POST / DELETE / PATCH) | 600 |
| read (GET doing fresh work) | 1,200 |
read-cached (cacheable catalog pre-flight; 304 / cache HIT does not debit read) | 12,000 |
Within a sandbox company the cap is split by route class (catalog, orders, finance, webhooks
management, general) so one chatty surface cannot starve another. Exceeding the cap returns
429 RATE_LIMIT_EXCEEDED with Retry-After.
GET /whoami reports data.key.rateLimited: false for production keys, true for sandbox keys.
Headers#
curl -s -X GET "https://api.avrix.io/api/seller/v1/whoami" \
-H "Authorization: Bearer $AVRIX_API_KEY"Responses include (and CORS exposes) these exact names:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Ceiling for the bucket that was checked |
X-RateLimit-Remaining | Remaining requests in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
Retry-After | Seconds to wait before retrying (especially on 429) |
Always prefer numeric Retry-After on 429s when present.
Client guidance#
- Back off on 429 using
Retry-After(cap your sleep; add jitter). - Prefer ETag / conditional GETs and the published catalog sync pattern — Caching and fairness.
- Do not busy-poll GET /orders or availability in a tight loop; use webhooks plus a slower reconciliation job.
- Hot-drop reserve/commit is for vendor-declared launches — see Hot drop.