Rate limits
Every response carries IETF-draft RateLimit headers, so you never have to
guess your remaining budget.
Reading the headers
ratelimit-policy describes the policy — static.
| Parameter | Meaning |
|---|---|
q=1000 | Quota: 1000 requests |
w=60 | Window: 60 seconds |
ratelimit describes your current state — changes per request.
| Parameter | Meaning |
|---|---|
r=976 | Requests remaining in this window |
t=60 | Seconds until the window resets |
The policy is "default" and is currently the same — 1000 requests per 60
seconds — on both the enterprise and vendor hosts.
Staying inside the budget
Read r and slow down as it falls, rather than sprinting until you are cut off:
Practical guidance:
- Prefer webhooks over polling. Polling every vendor order every few seconds is the fastest way to exhaust a quota. Webhooks cost nothing against it, and every vendor vertical documents them on its own page — see Vendor APIs.
- Ask for more per request. GraphQL lets you fetch related data in one round trip; use it instead of an N+1 loop.
- Use the largest page size a field accepts when paginating.
- Spread scheduled jobs. A nightly sync that fires everything at 00:00 will burst straight through the quota.
When you are limited
Exceeding the quota returns 429. Back off exponentially with jitter, and use
t from the ratelimit header — it tells you exactly how long until the window
resets, which is better than a guessed delay.
The OAuth token endpoint does not emit RateLimit headers. Cache your access
token for its expires_in rather than requesting a fresh one per call.
The counter appears to be shared per client across hosts rather than being a separate budget per endpoint — requests to different hosts decremented the same value in our testing. Treat your quota as one shared pool, which is the safe assumption either way.
Always log x-request-id on a 429. See Errors.