Policies & Limits

Rate limits and usage policies for the API.

Rate Limits

To ensure high availability, we enforce tier-based rate limiting on read endpoints (GET requests).

Tier Limits (GET endpoints)

Parameter	Required	Description
`Gold`	No	300 requests per minute.
`Platinum`	No	600 requests per minute.
`Diamond`	No	1,200 requests per minute.

POST /order is Exempt

The POST /api/v1/order endpoint is not rate-limited. Orders are self-rate-limited by your balance and protected by idempotency (ref_id deduplication). This ensures your integration is never blocked during peak demand.

Rate Limit Headers

We include the following headers in every response to help you track your limits: X-RateLimit-Limit · X-RateLimit-Remaining · X-RateLimit-Reset

If you exceed the rate limit, the API will respond with HTTP 429 Too Many Requests. If you need more requests per minute, kindly contact our support team.

Your limit is counted per account, across all our servers

Please read this if your traffic is high

The numbers in the table above have not changed. What changed is where we count them.

We run the API on several servers behind one address. Your requests get spread across those servers, and each server used to keep its own separate counter. So if you were sending 500 requests per minute on a Gold plan, that traffic could land as 170 requests on each of three servers, and no single counter ever reached 300. You would not get a 429, even though your account was above its published limit.

Your requests are now counted once for your whole account, no matter which server answers them. The number in the table is the real ceiling, and X-RateLimit-Remaining now reflects your entire account instead of one server’s slice of it.

What this means for you. If your integration has been running comfortably under the published limit, nothing changes and you will not notice anything. If it has been running above the published limit, you may start seeing 429 Too Many Requests where you did not before. Nothing about your API keys, signatures, headers, or request format has changed, so there is no code to migrate.

If you are getting 429s, here is what helps, in order:

Stop polling for order status. Set a callback URL and we push every status change to you the moment it happens. See Callbacks. This is usually the single biggest saving, because order-status polling is what fills most integrations’ budget.
Cache the catalog. GET /products and GET /categories change slowly. We already send Cache-Control: private, max-age=60, so honoring it costs you nothing.
Watch X-RateLimit-Remaining and back off when it gets low, rather than retrying immediately into a 429. Every 429 carries a Retry-After header telling you exactly how many seconds to wait.
Ask us to move you up a tier. If your volume genuinely needs a higher ceiling, that is a normal request and we would rather raise your tier than have you throttled. Contact support and we will look at your traffic with you.

We watch this too

We monitor accounts that get close to their limit and reach out before it becomes a problem. If we see your traffic climbing, expect a message from us first, not a wall of 429s.