Information about the restrictions on the number of times a user or client can access Commerce Layer API endpoints within a specified period of time.
To protect our platform against API misuse or overuse and ensure the system is available for all our users we adopt a rate-limiting strategy, differentiated by environment (test or live), HTTP method, and types of resources involved.
IP addresses that exceed the following rates will be blocked until the frequency of the specific call drops below the allowed limit. Please note that the count on the number of requests is never reset: you must consider the time intervals as sliding time windows (that's why no
X-Ratelimit-Resetheader is included in the response).
All the resources endpoint can be grouped into two main classes depending on whether they could be cached or not (cacheable or uncacheable). Two kinds of rate limits are applied to the IP with which you perform the calls to the
- Average — the number of requests is calculated considering the sum of the requests sent to all the resource endpoints of the specific class in the related time window (e.g. you cannot send 300 live reqs to the
/api/bundlesendpoint, 300 live reqs to the
/api/skus endpoint, and 300 live reqs to the
/api/pricesendpoint, all within the same 1-min window — because it would result in a total of 900 reqs / 1 min).
- Burst — the number of requests is calculated on each single resource endpoint of the specific class (e.g. you can send 25 test reqs to the
/api/addressesendpoint, 25 test reqs to the
/api/ordersendpoint, and 25 test reqs to the
/api/line_itemsendpoint, all within the same 10-sec window)
Read requests (performed via
OPTIONSHTTP methods) are subject to different rate limits based on the type of resource.
Please find below the list of cacheable resources. Read requests to the related endpoints are subject to the following rate limits:
- All types of promotions —
Write requests (performed via
PATCHHTTP methods) to any endpoint (regardless of whether the related resource falls into the cacheable or uncacheable category) are subject to the following rate limits:
You can get additional information you can use to avoid getting HTTP
429 Too many requestserrors or to understand why your calls are being blocked by inspecting some specific headers included in the response:
The following headers are still included in the response, but they are deprecated
and will be soon removed (please make sure to stop relying on them and update your integration/app to use the ones above):