Bron-API geeft 429 errors, hoe los ik dat netjes op?
429 betekent te veel requests in een tijdsvenster. Brute retryen versterkt het probleem. De juiste reactie is wachten precies zo lang als de bron aangeeft, en je flow zo bouwen dat je onder de limiet blijft.
Probeer dit eerst zelf
- 1Lees de Retry-After header en wacht exact die tijd. Niet je eigen 30 seconden er overheen plakken.
- 2Check de docs voor het rate-limit-budget per minuut of per uur. Bouw je flow met een throttle (Delay-stap, Sleep-node) onder die limiet.
- 3Splits batch-werk over meerdere kleinere runs verspreid over tijd: 100 records nu, 100 over 5 minuten, in plaats van 500 ineens.
- 4Voor APIs met een 'leaky bucket': spreid de calls gelijkmatig in plaats van burst-en-wacht. Dat haalt vaak meer doorvoer dan piek-belasting.
- 5Houd een interne teller per minuut bij in een Data Store. Als je je eigen quota nadert, wacht dan proactief in plaats van te wachten op de 429.
Wanneer ons inschakelen
Heb je een API-limiet die structureel knelt, dan is een queue-laag met throttle de oplossing. Daar kunnen we het patroon voor opzetten.
Zie ook
- n8n: zelf hosten of cloud-versie nemen?Self-hosted is goedkoper bij volume en geeft data-controle. Cloud spaart je de ops weg.
- Zapier of Make: welke past beter?Zapier is rechttoe-rechtaan, Make doet complexere flows met routers en iterators voor minder geld.
- Power Automate Cloud of Desktop: wat moet ik nemen?Cloud voor SaaS-koppelingen en triggers. Desktop voor RPA op een Windows-machine met legacy-apps.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.