Alle rate limits van de bol API, met de geschiedenis erbij

Op deze pagina staan alle 104 rate limits van de bol Partner API, opgehaald bij bol zelf en dagelijks opnieuw gecontroleerd. De laatste controle was op 31 augustus 2026.

bol publiceert de actuele limieten, maar bewaart geen geschiedenis: wijzigingen gaan naar de technisch contactpersoon van je account en verdwijnen daarna uit beeld. Wij leggen ze sinds 27 augustus 2026 elke dag vast, zodat je kunt terugzien wát er wanneer veranderde.

SolidDeploy houdt sinds 27 augustus 2026 dagelijks bij wat er verandert aan de rate limits van de bol Partner API. Voor zover wij weten is dit de enige openbare, gedateerde reeks; bol publiceert de actuele waarden maar bewaart geen geschiedenis.

De volledige reeks staat ook als machineleesbaar JSON-bestand op /data/bol-rate-limits.json: alle 104 limieten plus elke waargenomen wijziging, met datum. Vrij te gebruiken met bronvermelding naar deze pagina.

Waarom je dit nodig hebt

Eén limiet voor je hele koppeling aannemen gaat mis, want het verschil tussen endpoints is groot. Losse voorraadupdates mogen vijftig keer per seconde; een volledige export van je aanbod mag negen keer per uur. Dat is geen willekeur: bol duwt je richting kleine, gerichte wijzigingen en weg van het steeds opnieuw ophalen van je hele catalogus.

Let ook op het verschil tussen per seconde en per minuut. /retailer/orders mag 25 keer per minuut, dus gemiddeld eens per 2,4 seconden. Een koppeling die zo snel mogelijk door de pagina's loopt, is er in één seconde doorheen en zit dan 59 seconden op slot. Bouw een wachtrij met een vaste snelheid in plaats van het maximum te willen halen.

Retailer API (85 limieten)

Advertiser API (7 limieten)

Marketing Catalog API (10 limieten)

Wat er tot nu toe veranderd is

Sinds 27 augustus 2026 is er nog niets veranderd. Zodra dat gebeurt, verschijnt het hier met de datum erbij, inclusief de oude en de nieuwe waarde.

Ter vergelijking: bol heeft de limieten van de Retailer API op 17 juli 2026 verhoogd. Dat is precies het soort wijziging dat je koppeling stilletjes raakt en waarvan achteraf niet meer te zien was wat de oude waarde was. Vanaf nu wel.

Wie dit bijhoudt, en hoe

Een script haalt elke dag https://api.bol.com/retailer/public/ratelimits op, vergelijkt het met de meting van de vorige dag en schrijft alleen bij verschil een nieuwe regel weg. Ongewijzigde dagen slaan alleen een datumstempel op.

Dat is geen bijzondere techniek, het is precies het soort automatisering dat wij voor klanten bouwen: iets in de gaten houden dat verandert zonder dat iemand het je vertelt. Geschikt voor: iedereen die een koppeling met bol onderhoudt en niet wil ontdekken dat er iets veranderd is doordat het stukging.

Veelgestelde vragen

Wat gebeurt er als ik over de rate limit ga?

Je krijgt een 429 Too Many Requests terug, met een Retry-After-header die aangeeft hoeveel seconden je moet wachten. Elke response bevat bovendien headers met je resterende budget en het moment waarop het wordt aangevuld. Een koppeling die die headers uitleest hoeft nooit tegen een 429 aan te lopen.

Hoe voorkom ik dat ik tegen de rate limits van de bol API aanloop?

Drie dingen. Lees de rate limit-headers uit elke response, dan weet je hoeveel budget je nog hebt voordat je eroverheen gaat. Bouw je synchronisatie op wijzigingen en niet op vergelijken, want een volledige export mag maar negen keer per uur terwijl losse voorraadupdates vijftig keer per seconde mogen. En gebruik een wachtrij met een vaste snelheid in plaats van zo snel mogelijk te gaan: /retailer/orders mag 25 keer per minuut, dus wie dat in één seconde opmaakt zit daarna 59 seconden stil.

Verandert bol deze limieten?

Ja. bol geeft zelf aan dat limieten omhoog of omlaag kunnen om de stabiliteit van de API te waarborgen, en heeft ze op 17 juli 2026 nog verhoogd. Wijzigingen worden gecommuniceerd aan de technisch contactpersoon van je account. Wie die mail mist, merkt het pas als er iets stukgaat. Daarom leggen wij de waarden dagelijks vast.

Gelden de limieten per account of per applicatie?

Per API-client. Werk je namens meerdere verkopers, dan heeft elke verkoper zijn eigen budget, maar deel je één client over meerdere processen, dan delen die processen ook het budget. Dat is de meest voorkomende oorzaak van onverwachte 429's: twee cronjobs die niets van elkaar weten.

Waarom mag een export maar negen keer per uur?

Omdat een volledige export van je aanbod aan bol's kant duur is. De boodschap achter dat getal is dat je je synchronisatie op wijzigingen moet bouwen en niet op vergelijken. Wie elke tien minuten de hele lijst ophaalt om te zien wat er anders is, zit na een uur zonder budget.

Mag ik deze gegevens overnemen?

Ja, met bronvermelding naar deze pagina. De JSON op /data/bol-rate-limits.json is daarvoor bedoeld. De onderliggende waarden komen van bol; wat wij toevoegen is de dagelijkse meting en het gedateerde overzicht van wijzigingen.