Polling versus webhooks

Wat is polling versus webhooks?

Polling en webhooks zijn de twee manieren waarop jouw systeem verneemt dat er ergens anders iets gebeurd is. Bij polling stel jij de vraag: om de zoveel minuten belt je integratie het andere systeem op en checkt of er iets veranderd is. Bij een webhook belt dat andere systeem jou, met een kort bericht naar een URL die je op voorhand opgaf, op het moment zelf.

Het enige echte verschil is wie de oproep start, en al de rest volgt daaruit: hoelang je op het nieuws wacht, hoeveel API-aanvragen je eraan spendeert, en aan welke kant het werk ligt om te zorgen dat er niets verloren gaat.

Polling is elke ochtend je leverancier bellen om te vragen of je bestelling vertrokken is. Een webhook is de leverancier die jou belt zodra ze vertrekt.

Hoe werkt elk van de twee?

Een polling-integratie houdt een bladwijzer bij: het tijdstip van de laatste wijziging die ze zag, of het id van het laatste record dat ze inlas. Bij elke ronde vraagt ze de API om alles na die markering en schuift ze de markering op. Microsoft omschrijft de polling-triggers van Power Automate net zo: een trigger die een status zet, om het interval kijkt, en alle data opvraagt sinds die status. Die markering juist krijgen is het grootste deel van het werk, want een oplopend id toont je nooit een aanpassing aan een ouder record, dus filter je meestal op een laatst-gewijzigd-kolom.

Een webhook heeft dat niet nodig. Je registreert eenmalig een URL bij de bron, duidt aan welke events je wil, en vanaf dan stuurt de bron een HTTP POST met een kleine payload zodra er een gebeurt. Geen lege aanvragen, en de vertraging is seconden in plaats van een volledig interval. Wat je opgeeft, is de zekerheid dat je het opnieuw kan vragen: een polling-ronde die je mist kost je niets, want de volgende raapt alles op sinds de markering, terwijl een event dat je endpoint niet aannam weg is zodra de afzender stopt met proberen.

Wat je endpoint moet aankunnen bij webhooks

Een webhook-URL staat open op het internet en iedereen die ze kent kan er iets naartoe sturen. De ontvanger draagt daardoor verplichtingen die een polling-job nooit heeft.

1. Controleer de handtekening voor je ook maar een veld gelooft. Stripe ondertekent elke levering in de header Stripe-Signature, GitHub doet hetzelfde in X-Hub-Signature-256. Reken op de ruwe body van de aanvraag, niet op een opnieuw geserialiseerde versie.

2. Bevestig snel, werk daarna. GitHub verwacht binnen de tien seconden een antwoord in de 2XX-reeks, en Stripe zegt je een 2xx terug te sturen voor je aan logica begint die in een timeout kan lopen. Je endpoint schrijft de payload weg naar een queue, geeft 200 terug, en een achtergrondproces doet de rest.

3. Ontdubbel op het event-id. Hetzelfde event kan twee keer binnenkomen, meestal omdat jouw 200 de afzender niet bereikte, dus raadt Stripe aan de verwerkte ids bij te houden en de bekende over te slaan. Ook de volgorde ligt niet vast: doet die ertoe, haal dan de actuele stand van het object op via de API in plaats van ze uit de events te reconstrueren.

4. Geef mislukkingen een plek om te landen. Een verwerker die een payload niet verwerkt krijgt, probeert het opnieuw met groeiende pauzes en parkeert het bericht daarna in een dead-letter queue, zodat een enkele foute bestelling de rest niet blokkeert.

5. Poll toch, als vangnet. Shopify is daar heel direct over: je app hoort niet te steunen op wat er via webhooks binnenkomt, en hoort periodieke reconciliatie-jobs te draaien die de data via de API ophalen zodat alles gelijk blijft lopen.

Bestelstatus van je webshop naar je ERP

Neem een shop met 40 bestellingen per dag die in het ERP moeten belanden zodat het magazijn kan picken. Poll je de bestellingen-API om de vijf minuten, dan doe je 288 aanvragen per dag waarvan er zowat 250 leeg terugkomen, en wacht een bestelling gemiddeld tweeënhalve minuut, in het slechtste geval vijf. Een uurlijkse poll kost 24 aanvragen, maar duwt die wachttijd naar een half uur. Ligt de poller een voormiddag plat, dan verlies je niets: de ronde van de middag raapt alles op sinds de markering.

Met een webhook stuurt de shop 40 leveringen per dag en weet het ERP het binnen de seconden, maar dan heb je wel een endpoint nodig dat van buitenaf bereikbaar is, met handtekeningcontrole, ontdubbeling, en een antwoord op de ochtend dat je ERP in onderhoud ligt en er twaalf bestellingen gepusht worden naar een URL die 503 teruggeeft. Waar de meeste shops op uitkomen is allebei: de webhook doet het dagelijkse werk, en een nachtelijke job vraagt de shop om alle bestellingen van de laatste 48 uur en maakt aan wat het ERP nooit ontvangen heeft.

Hoe kies je?

Je kan de hele architectuurdiscussie overslaan met een vraag: wat kost het je als je dit event tien minuten te laat verneemt? Bij een betaling die een download vrijgeeft, is tien minuten een supportticket. Bij een lead van je website die bij een verkoper moet raken zolang de prospect nog warm is, is tien minuten het verschil tussen een gesprek en een voicemail. Bij een boekhoudkundige export is het niets.

Twee praktische grenzen versmallen het verder. Rekent de bron per API-call aan of hangt er een strakke rate limit op, dan wordt een kort polling-interval duur en verdient de webhook zichzelf terug. En heeft je ontvangende systeem geen publiek HTTPS-adres, een laptop of een server achter de firewall, dan is polling de optie die werkt, want dan vertrekt de oproep bij jou naar buiten.

Waar moet je op letten bij polling en webhooks

Heel wat systemen bieden geen van beide aan
Oudere ERP-pakketten, sectorsoftware en de meeste on-premises toepassingen hebben geen meldingen en geen bruikbare API. Dan zak je een laag: een trigger op de database die wijzigingen wegschrijft naar een outbox-tabel die jij uitleest, een geplande export als bestand in een map, of Change Data Capture dat het transactielog meeleest.

Niet alle leveranciers hebben betrouwbare webhooks
Webhooks zijn niet gestandaardiseerd. Er bestaat geen IETF-standaard voor, en het dichtste wat je hebt is Standard Webhooks, een community-specificatie gedragen door mensen van Zapier, Twilio, ngrok en Kong, waarvan de openingszin zelf toegeeft dat elke aanbieder webhooks anders en met wisselende kwaliteit implementeert. Stripe probeert een mislukte levering tot drie dagen lang opnieuw, terwijl andere leveranciers het een keer proberen en geen leveringslogboek bijhouden. Lees eerst dat beleid, en staat er niets, behandel de webhook dan als een tip en laat de reconciliatie-poll bepalen wat waar is.