Rate Limiting
To ensure our platform remains stable and fair for everyone, all APIs are rate-limited. We use a variety of strategies to enforce rate limits. We ask developers to use industry standard techniques for limiting calls, caching results, and re-trying requests responsibly.
Rate limits apply based on the plan you are subscribed to, this table clarifies how it works.
Plan | Max Requests | Timeout duration | Leak limit |
---|---|---|---|
Plus | 120 | 1 minute | 1 request per second |
Pro | 360 | 1 minute | 1 request per second |
Special | 720 | 1 minute | 1 request per second |
according to your plan, you have x Max requests
per 1 minute (Timeout duration
), if you consumed all the requests before the minute ends, you can have 1 request per second (the leak limit
) until the mintue is over and another minute begins.
Limits are calculated using the leaky bucket algorithm. All requests that are made after rate limits have been exceeded are throttled and an HTTP 429
Too Many Requests error is returned.
Requests succeed again after enough requests have emptied out of the bucket. You can see the current state of the throttle for a store by using the rate limits header.
Rate limits will be returned with every request in following headers:
X-RateLimit-Limit
This header, x-ratelimit-remaining
, will contain the number of calls per minute that can be made to the API before rate limiting will take effect. This can either have a value of 60, 120 or 180 depending on the store plan.
X-RateLimit-Remaining
This header, x-ratelimit-remaining
, will contain the number of calls the API has left in the current rate limit window.
Retry-After
This header will contain the number of seconds in which the API will become available after its rate limit has been exceeded.
X-RateLimit-Reset
This header, x-ratelimit-reset
, will contain the time at which an API's current rate limit window resets, in UTC epoch seconds.
If the bucket size is exceeded, then an HTTP 429
Too Many Requests error is returned. The bucket empties at a leak rate
of one requests per second. To avoid being throttled, you can build your app to average one requests per second. The throttle is a pass or fail operation.
Having trouble ?
Please don't hesitate to contact us using the support methods here: