API Rate Limiting bij Integraties: Zo Voorkom je dat je Koppeling Wordt Geblokkeerd

Door Clen Mourik

Je integratie werkt perfect. Tot het opeens niet meer werkt. Wat 62% van de MKB-bedrijven niet weet: hun systeemkoppelingen worden regelmatig stilgelegd door rate limits — en ze hebben het niet eens door.

Je opent maandagochtend je laptop. 47 nieuwe orders van het weekend. Je automatische koppeling heeft ze netjes naar je voorraadsysteem gestuurd. Denk je. Want als je je boekhouding opent, zie je dat er sinds zaterdagochtend 09:43 uur niks meer is binnengekomen.

Wat er gebeurd is? Je integratie heeft de API rate limit van je boekhoudpakket bereikt en is sindsdien stil blijven staan. Je bent nu twee dagen aan orders aan het naboekhouden. Handmatig.

Dit is geen theoretisch probleem. Bij SyncIT zien we dit meerdere keren per maand bij bedrijven die denken dat hun koppeling "gewoon werkt". Tot het moment dat het niet meer werkt.

Inhoudsopgave

• Belangrijkste punten
• Wat zijn API rate limits precies?
• Waarom rate limits een groter probleem zijn dan je denkt
• 7 fouten die je integratie laten crashen
• Hoe je rate limit problemen herkent voordat het misgaat
• 5 strategieën om rate limiting te voorkomen
• Rate limits bij populaire MKB-systemen
• Wanneer kies je welke aanpak?
• Veelgestelde vragen

Belangrijkste punten

Wat zijn API rate limits precies?

Een API rate limit is een beschermingsmechanisme. Elk systeem — of het nu Shopify, Exact Online of AFAS is — heeft een maximaal aantal verzoeken dat het per tijdseenheid kan verwerken.

Stel je voor: je bouwbedrijf heeft 18 monteurs. Om 16:45 uur tikken ze allemaal hun uren in. Je automatische koppeling probeert die 18 urenmutaties in één keer naar AFAS te sturen. AFAS ziet dit als verdacht gedrag en blokkeert je tijdelijk.

De meest voorkomende rate limit methode heet "Token Bucket". Je krijgt een emmer met tokens. Elke API call kost een token. De emmer vult zich weer met een bepaalde snelheid. Als je emmer leeg is, moet je wachten.

De HTTP 429 response

Als je de limiet bereikt, krijg je een HTTP 429 status code terug: "Too Many Requests". Dit is de standaard volgens IETF RFC 6585. De meeste systemen sturen ook een "Retry-After" header mee die aangeeft hoeveel seconden je moet wachten.

Het probleem? Veel koppelingen zijn niet gebouwd om deze foutmelding netjes af te handelen. Ze crashen gewoon.

Waarom systemen rate limits hanteren

Elk softwarebedrijf wil voorkomen dat één klant de hele server platlegt. Een webshop die elke seconde duizend producten opvraagt, verstoort de service voor alle andere gebruikers. Vandaar de limieten.

Voor groothandels, productiebedrijven en installateurs is dit extra frustrerend. Je wilt gewoon je eigen data synchroniseren tussen je eigen systemen. Maar die systemen delen infrastructuur met duizenden andere bedrijven.

Waarom rate limits een groter probleem zijn dan je denkt

Wat veel ondernemers niet doorhebben: je maakt waarschijnlijk véél meer API calls dan je denkt.

Een gemiddelde webshop met WooCommerce die elke 5 minuten de voorraad checkt van 2000 producten, maakt 576.000 calls per dag. Alleen al voor voorraad. Tel daar je ordersync, klantdata en verzendlabels bij op en je zit al snel boven de miljoen.

Wat ik in de praktijk vaak zie: bedrijven bouwen een koppeling, testen met 10 orders, en denken dat het werkt. Dan komt Black Friday, 300 orders in twee uur, en ineens staat alles stil.

De kosten van een geblokkeerde koppeling

Reken maar mee. Een e-commerce bedrijf met 200 orders per dag dat 2 uur vast staat door rate limiting, mist gemiddeld 17 orders. Bij een gemiddelde orderwaarde van €75 is dat €1.275 aan omzet. Per incident.

Maar de échte kosten zitten in de opvolgtijd. Iemand moet handmatig orders naboekhouden, voorraad corrigeren, klanten informeren. Tel daar 4 uur werk bij op tegen €35 per uur, en je incident kost je €1.400.

Voor een aannemersbedrijf zijn de cijfers anders maar het principe hetzelfde. Als je urenregistratie twee dagen niet synchroniseert met je facturatie, loop je achter met je declaraties. Gemiste cashflow, ontevreden klanten, extra administratieve rompslomp.

7 fouten die je integratie laten crashen

1. Geen error handling voor 429 responses

De klassieke fout. Je koppeling stuurt data, krijgt een 429 terug, en weet niet wat ie ermee moet. Resultaat: crash. Alles stopt. Ook de orders die WEL binnen de limiet passen, worden niet meer verwerkt.

Wat je moet doen: check elke response op de status code. Als het 429 is, lees de Retry-After header en wacht die tijd. Simpel, maar vaak vergeten.

2. Infinite retry loops

Nog erger: koppelingen die automatisch opnieuw proberen zonder pauze. Je API call wordt afgewezen, dus je probeert direct opnieuw. Nog een keer afgewezen. Nog een keer. Voor je het weet heb je 500 extra calls gemaakt die allemaal afgewezen worden.

Sommige systemen verhogen zelfs je blokkeertijd als je te agressief blijft proberen. Je maakt het dus erger.

3. Alle systemen tegelijk aanroepen

Een order komt binnen. Je koppeling roept direct je boekhouding aan, je voorraadsysteem, je verzendpartner, en je CRM. Vier calls tegelijk. Als één systeem een rate limit heeft, stagneert je hele proces.

Beter is sequentieel werken. Eerst de kritieke calls (order opslaan), dan de minder urgente (CRM updaten).

4. Geen monitoring van je API budget

Hoeveel calls maakt jouw integratie per dag? Geen idee? Dan weet je ook niet wanneer je tegen je limiet aanloopt. Bij een project bij een technische groothandel ontdekten we dat hun voorraadsync 340.000 calls per dag maakte. Hun API limiet was 200.000.

Ze wisten het pas toen hun koppeling elke middag rond 14:00 uur vastliep. Logisch — dan zaten ze aan hun daglimiet.

5. Peak loads negeren bij het testen

Je test je koppeling met 10 orders. Werkt perfect. Maar wat gebeurt er bij 100 orders in een uur? Of als je een actie draait en je verkoopt 500 producten op één dag?

Peak loads zijn waar rate limits echt pijn gaan doen. En die test je bijna nooit voordat je live gaat.

6. Rate limits per endpoint niet kennen

Niet alle API endpoints hebben dezelfde limiet. Bij HubSpot mag je bijvoorbeeld meer contact-gegevens ophalen dan aanmaken. Bij Bol.com mag je prijzen maar 1 keer per seconde updaten, terwijl je voorraad sneller mag aanpassen.

Als je dit niet weet, bouw je een koppeling die bij sommige acties continu geblokkeerd wordt.

7. Webhooks negeren

Veel systemen bieden webhooks aan. Real-time notificaties als er iets wijzigt. Maar ondernemers blijven polling gebruiken: elke 5 minuten alles checken of er wijzigingen zijn.

Polling verbruikt 288 calls per dag. Per item. Webhooks: 0 tot het moment dat er écht iets wijzigt. Het verschil is enorm.

Hoe je rate limit problemen herkent voordat het misgaat

De meeste bedrijven merken pas dat ze een rate limit probleem hebben als het al dagenlang fout gaat. Voorraad klopt niet meer, orders komen niet door, klanten bellen.

Dat kan slimmer.

Check deze HTTP headers

De meeste API's sturen informatie mee over je rate limit status. Let op deze headers (de exacte namen verschillen per systeem):

• X-Rate-Limit-Limit — hoeveel calls je maximaal mag doen
• X-Rate-Limit-Remaining — hoeveel je nog over hebt in deze periode
• X-Rate-Limit-Reset — wanneer je quota reset (timestamp)
• Retry-After — hoeveel seconden je moet wachten na een 429

Als je "Remaining" onder de 20% zakt, is het tijd om je sync te vertragen. Voor je tegen de limiet aanloopt.

Log je 429 responses

Elke keer dat je een 429 krijgt, schrijf dat weg naar een log. Met timestamp, endpoint, en hoeveel calls je die minuut had gemaakt. Na een week heb je een mooi overzicht van je probleemmomenten.

Bij een installatiebedrijf zagen we zo dat ze elke dag tussen 16:00 en 17:00 uur tegen hun limiet aanliepen. De oplossing: start de urensync al om 15:00 uur, zodat tegen 17:00 uur alles klaar is.

Monitor je call volume

Houdt bij hoeveel calls je per uur, per dag, per endpoint maakt. Niet achteraf, maar real-time. Zo zie je trends en kun je ingrijpen voordat het misgaat.

Een simpele grafiek laat je zien: elke zaterdagochtend een piek (weekend-orders), elke eerste van de maand een piek (facturen), rond lunch een dip (weinig activiteit).

5 strategieën om rate limiting te voorkomen

1. Queueing: de wachtrij-methode

Stop al je API calls in een wachtrij. Verwerk ze één voor één, met pauzes ertussen. Zo voorkom je dat je in één keer 100 calls afvuurt en je limiet raakt.

Een speelgoedwinkel die we hielpen, synchroniseerde elk uur 800 producten. In plaats van alle 800 in één keer te updaten, verdelen we dat nu over het hele uur. Elke 4,5 seconden een product. Geen stress, geen rate limits.

2. Batching: meerdere acties in één call

Sommige API's ondersteunen batch-requests. In plaats van 50 losse calls voor 50 producten, doe je 1 call met alle 50 producten tegelijk.

Let op: niet alle systemen ondersteunen dit. En sommige systemen rekenen een batch van 50 items als 50 calls voor je rate limit. Lees de documentatie.

3. Caching: onthoud wat je al weet

Hoeveel keer per dag vraag je dezelfde klantgegevens op? Bij elk order? Dat kan slimmer. Bewaar klantdata lokaal en ververs alleen als het nodig is.

Een groothandel in technische installatiematerialen vroeg bij elk order de klantgegevens op uit Exact Online. 120 orders per dag = 120 calls. Nu cachen we klantdata voor 24 uur. Resultaat: 5 calls per dag in plaats van 120.

4. Exponential backoff: wachten met toenemende tijd

Als je een 429 krijgt, wacht dan niet altijd dezelfde tijd. Start met 1 seconde, dan 2, dan 4, dan 8. Zo geef je het systeem steeds meer tijd om te herstellen.

Google Cloud adviseert dit als standaard strategie. Het vermindert onnodige calls met 60-80% tijdens herstel.

5. Webhooks in plaats van polling

Stop met elke 5 minuten checken of er iets gewijzigd is. Laat het systeem JOU notificeren als er iets gebeurt. Dat scheelt duizenden calls per maand.

Bij een webshop met Shopify en Picqer schakelden we van polling naar webhooks. Van 12.000 voorraad-checks per dag naar 50 notificaties. 99,6% minder API calls.

Het grappige is: webhooks zijn vaak makkelijker te bouwen dan polling. Maar omdat ondernemers denken dat ze ingewikkelder zijn, kiezen ze voor de API-intensieve methode.

Rate limits bij populaire MKB-systemen

Elk systeem hanteert andere limieten. Hier een overzicht van systemen waar we dagelijks mee werken bij SyncIT:

Shopify: de 2-per-seconde uitdaging

Shopify's limiet van 2 calls per seconde klinkt ruim. Maar bij 800 producten duurt een volledige sync minimaal 400 seconden — 6,5 minuut. En dat is als je NIETS anders doet.

In de praktijk draait er altijd meer. Orders binnenhalen, klanten updaten, voorraad synchroniseren. Tel alle processen bij elkaar op en je zit snel aan je limiet.

Exact Online: de 300-per-minuut grens

300 calls per minuut klinkt als veel. Tot je beseft dat een gemiddelde order 3-4 calls kost: klantgegevens ophalen, order aanmaken, voorraad updaten, status terugsturen.

Bij 30 orders in 10 minuten zit je aan 120 calls. Tel daar je andere processen bij op (facturen, offertes, mutaties) en die 300 is sneller bereikt dan je denkt.

AFAS: de onduidelijke fair use

AFAS heeft geen publieke limiet. Ze hanteren een "fair use" principe. Klinkt relaxed, maar in de praktijk betekent het: als je té veel calls maakt binnen kort tijdsbestek, word je tijdelijk geblokkeerd.

Wat "té veel" is? Dat verschilt per situatie. Bij een bouwbedrijf liepen we tegen blokkades aan bij 50+ urenmutaties binnen 2 minuten. De oplossing: spreiding. Maximaal 5 mutaties per minuut.

Wanneer kies je welke aanpak?

Niet elke strategie past bij elk bedrijf. Het hangt af van je volumes, je systemen, en hoe real-time je data moet zijn.

Kleine volumes (tot 50 transacties per dag)

Bij kleine volumes zijn rate limits zelden een probleem. Een eenvoudige koppeling zonder fancy queueing is vaak genoeg. Let wel op: test ook piekbelasting. Die ene keer dat je 100 orders op één dag hebt, moet het ook werken.

Advies: directe koppeling met basic retry-logica (max 3 pogingen, wacht 5 seconden tussen pogingen).

Gemiddelde volumes (50-200 transacties per dag)

Hier wordt het interessant. Je hebt genoeg volume om regelmatig tegen rate limits aan te lopen, maar niet zoveel dat je meteen complexe oplossingen nodig hebt.

Advies: queueing met throttling. Verwerk transacties in batches, spreid ze over de dag. Gebruik webhooks waar mogelijk om polling te vermijden.

Hoge volumes (200+ transacties per dag)

Bij hoge volumes is rate limit management essentieel. Zonder goede architectuur loop je constant tegen problemen aan. Je hebt monitoring nodig, logging, exponential backoff, het hele pakket.

Advies: professioneel gebouwde middleware met ingebouwde rate limit handling. Denk aan message queues (RabbitMQ), caching layers, en real-time monitoring. Iets wat je bij SyncIT standaard krijgt bij grote integraties.

Multi-systeem omgevingen

Als je data synchroniseert tussen 3+ systemen, heb je een orkestratielaag nodig. Elk systeem heeft andere rate limits, verschillende response tijden, en eigen error handling.

Advies: centrale integratielaag die alle communicatie regelt. Zo kun je per systeem de optimale strategie toepassen zonder dat je overal dubbele logica hebt.

Bij een fashion webshop die verkoopt via eigen site, Bol.com én Amazon, bouwen we één centrale hub. Die spreekt met alle systemen, houdt alle rate limits bij, en zorgt dat alles soepel loopt. Voor de ondernemer voelt het als één koppeling.

Praktische tips voor stabiele koppelingen

Een paar concrete dingen die je vandaag nog kunt checken:

• Lees de API documentatie. Ja, echt. Weet welke limieten gelden voor jouw systemen. Shopify heeft een andere limiet dan WooCommerce, Exact Online andere regels dan Twinfield.
• Log je API calls. Weet hoeveel calls je maakt, wanneer, naar welk endpoint. Na een week zie je patronen.
• Test met realistische volumes. Niet 10 testorders, maar 100. Simuleer een piekdag.
• Bouw retry-logica in. Als je een 429 krijgt, wacht dan en probeer opnieuw. Klinkt simpel, maar veel koppelingen hebben dit niet.
• Monitor je "Remaining" header. Als je onder 20% zakt, vertraag dan automatisch.

Voor ontwikkelaars: een simpele retry functie

Dit is geen tutorial, maar één tip voor wie zelf aan integraties bouwt: check altijd op 429 responses en implementeer exponential backoff. De meeste API crashes zijn te voorkomen met 10 regels code.

Meer technische details vind je in onze kennisbank, waar we dieper ingaan op implementatie-specifieke uitdagingen.

Veelgestelde vragen

Hoe weet ik of mijn koppeling rate limit problemen heeft?

Check je logs op 429 errors. Als die er zijn, heb je een probleem. Zie je orders of data die niet zijn gesynchroniseerd terwijl je systeem aangeeft dat alles werkt? Ook verdacht. Monitor je API call volume en vergelijk met de limieten van je systemen.

Kan ik een hogere rate limit aanvragen bij mijn softwareleverancier?

Soms wel. Bij Picqer kun je bijvoorbeeld een hogere limiet aanvragen als je een valide use case hebt. Bij Shopify betaal je voor Shopify Plus en krijg je iets meer ruimte. Maar de meeste systemen houden vast aan hun standaard limieten. Beter is je architectuur aanpassen.

Wat kost het om rate limit handling toe te voegen aan mijn bestaande koppeling?

Dat verschilt enorm. Een simpele retry-logica toevoegen: paar uur werk. Een volledige queueing-oplossing bouwen met monitoring en exponential backoff: een paar dagen. Afhankelijk van hoe complex je huidige setup is. Bij SyncIT bouwen we dit standaard in bij nieuwe koppelingen.

Zijn er systemen zonder rate limits?

Vrijwel geen enkel modern systeem heeft géén rate limits. Sommige zijn alleen vager over de exacte grenzen (zoals AFAS met "fair use"). Maar zelfs die blokkeren je als je het te bont maakt. Ga er dus altijd vanuit dat er limieten zijn.

Werkt mijn koppeling langzamer als ik rate limit handling toevoeg?

Ja en nee. Individuele transacties kunnen iets langer duren door de throttling. Maar je systeem crasht niet meer, dus je totale doorvoer gaat omhoog. Liever 1000 orders per dag op een stabiele manier verwerken dan 1200 proberen en na 500 crashen.

Kan ik meerdere API keys gebruiken om meer calls te mogen maken?

Bij sommige systemen technisch wel mogelijk, maar vaak tegen de voorwaarden. Shopify bijvoorbeeld detecteert dit en kan je account blokkeren. Bovendien lost het het onderliggende probleem niet op — je architectuur is inefficiënt.

Wat is het verschil tussen rate limiting en throttling?

Throttling is wat jij doet (je eigen calls vertragen om binnen de limiet te blijven). Rate limiting is wat het externe systeem doet (je blokkeren als je de limiet overschrijdt). Je gebruikt throttling om rate limiting te voorkomen.

Tijd om je koppeling toekomstbestendig te maken

Rate limits zijn geen randprobleem. Ze zijn een realiteit waar elk bedrijf met systeemkoppelingen mee te maken krijgt. Vroeg of laat.

Het goede nieuws: met de juiste architectuur zijn ze te voorkomen. Queueing, caching, webhooks, exponential backoff — het zijn allemaal bewezen strategieën. Je hoeft het wiel niet opnieuw uit te vinden.

Wat je WEL moet doen: bewust zijn van het probleem voordat het optreedt. Test met realistische volumes. Monitor je API gebruik. Bouw retry-logica in. Kleine aanpassingen die grote problemen voorkomen.

Bij SyncIT bouwen we dit standaard in bij alle koppelingen die we maken. Voor aannemers, groothandels, webshops, productiebedrijven — wie dan ook. Want een integratie die af en toe crasht, is geen integratie. Het is een potentieel probleem.

Twijfel je of jouw huidige koppeling goed omgaat met rate limits? Of wil je een nieuwe integratie bouwen die vanaf dag één stabiel draait? Plan een gesprek met ons team. We kijken naar je specifieke situatie en adviseren wat de beste aanpak is. Geen verplichtingen, gewoon helder advies.