Rate limits: de stille sluipmoordenaar van koppelingen
Je koppeling werkt in test. Je rolt 'm uit. Tijdens de eerste bulk-sync van 10.000 records valt alles stil. Gefeliciteerd, je hebt kennisgemaakt met rate limits.
Wat zijn rate limits?
API-providers beperken hoeveel requests je per tijdsvenster kunt doen. Shopify hanteert bijvoorbeeld een bucket-model, Exact Online 60 calls per minuut per divisie, en Mollie publiceert geen harde limiet maar handhaaft fair use.
Tijdens development merk je hier zelden iets van, je test immers met 3 records. In productie, bij een initiële data-import, loop je vol.
Wat doe je eraan?
Drie basisprincipes die in elke koppeling thuishoren:
- Exponential backoff: bij een HTTP 429-response wacht je langer vóór de retry. Begin bij 1 seconde, verdubbel bij elke volgende fout.
- Respecteer de
Retry-After-header: providers geven vaak expliciet aan hoe lang je moet wachten. - Throttle preventief: plan je bulk-jobs zo dat je ónder de limiet blijft, niet tot op de grens. Een kleine buffer bespaart veel hoofdpijn.
Waarom wij het documenteren
Op elke software-detailpagina vind je het veld “rate limit”, wat de provider publiceert, of “Niet gespecificeerd” als er niets over bekend is. Dat laatste betekent níét “geen limiet”, maar “wees voorzichtig en meet zelf”.
Ook interessant
Apikoppeling.nl in een nieuw jasje
Apikoppeling.nl is vernieuwd. De site is sneller, de catalogus is flink uitgebreid en je ziet nu direct welke data-objecten twee pakketten met elkaar kunnen uitwisselen.
Payments als aparte categorie
Stripe, Mollie, Wise, Paddle en Square hebben hun eigen karakteristieken die niet helemaal passen bij de categorie Boekhouding. Daarom is er nu een Payments-categorie.
