Rate limits

300 requests per minute per token. The window is a fixed minute, and each token gets its own budget — your script and the merchant's browser session no longer share one.

Every response carries what is left:

X-RateLimit-Limit: 300
X-RateLimit-Remaining: 271

Going over returns 429 with the seconds to wait:

HTTP/1.1 429 Too Many Requests
Retry-After: 23

Some paths are tighter on purpose — authentication (5/min), checkout (10/min) and OTP (10/min) — because they are the ones worth attacking. Those limits are per IP, not per token.

Handling 429 properly

Honour Retry-After, and add jitter so a fleet of workers does not retry in lockstep.

JavaScript

Python

Staying well under

Prefer webhooks to polling. An integration that polls orders every ten seconds burns its budget and still learns late. Subscribe instead.

Filter server-side. ?status=processing&limit=100 beats fetching everything and filtering locally.

Page sequentially, not in parallel.

Cache what rarely changes — categories, settings, shipping zones.

Batch your writes where an endpoint accepts a list.

If you need more

Tell us what you are building and the shape of the traffic: engineering@numueg.app. Higher per-token limits are a conversation, not a form.

Handling 429 properly#

Staying well under#

If you need more#

Handling 429 properly

Staying well under

If you need more