The retailer API makes active use of rate limiting. Being a heavily used API, we have to take measures to try to guarantee maximum stability and uptime for all of our users. Sometimes the API gets hits with extreme volumes of requests, and allowing those to reach the internal landscape at bol.com makes it difficult to make these guarantees.
We strive to configure rate limits at thresholds that allow our users to do the calls they need to do in the time they need to do them. This, however, does not mean we are going to provide unlimited budget for doing requests.
Keep track of your changes - Only send those updates that actually reflect a change in your internal systems that needs to be synchronized with bol.com. Please try to prevent sending everything - even if it is not updated - as this will eventually give you issues with the rate limits.
Make use of the rate limit headers - Every response contains information on rate limits, such as how much request budget you have left, when the budget will be replenished and so on. You can use these settings automatically by programming against them, so your implementation will keep working even if the rate limits change over time.
Monitor the responses you receive - We will send 429 responses when you hit a rate limit. We are monitoring and logging excessive volumes of 429 responses and will get in touch with you if you are causing them. You can prevent this by monitoring the responses returned from the API and by stopping requests if you see the 429s coming in. As mentioned in the previous tip, you can use the headers to determine how long you will have to back off from doing additional requests to prevent 429 responses.
Prevent batching - We are aware that some API implementations are batch-oriented. We have adopted a more event-oriented approach, where we want to be aware of changes when they happen. If a price change is executed in the internal systems, send us the event. If a stock update is processed for an offer, send us the event. The faster we are aware of the changes, the faster we can propagate them to the webshop, which will benefit you in reaching your potential customers. This will also help deal with the rate limits, as they are optimized for a steady flow of updates over time, rather than a big batch of updates every hour or so.
See below for the rate limits currently enforced by the retailer API.
If you want to request the rate limits from your application to automatically process them, find them here:
You can use the provided endpoint to stay up to date with rate limit changes, or retrieve the active limits from the rate limiting headers that we provide with every request.
The Retailer API is heavily used, and we define rate limits to allow retailers to do what they need to do on the API, but also to protect the services that provide the functionality. This is a tough balancing act and sometimes may lead to configurations that may or may not work for you. Feel free to reach out to Partner Service to discuss the rate limits if they are proving to be problematic. We are always looking for the optimal settings.