Webhook

Wat is een webhook?

Een webhook is een omgekeerde API-aanroep. Bij een klassieke API stel jij de vraag: jouw systeem klopt aan bij een ander systeem om te checken of er nieuws is. Bij een webhook draait dat om. Het systeem waar iets gebeurt, roept jou op zodra het gebeurt.

Vergelijk het met een deurbel. Zonder deurbel loop je om de vijf minuten naar de voordeur om te kijken of er iemand staat. Met een deurbel werk je gewoon verder tot er gebeld wordt. Een webhook is die deurbel voor je software: je krijgt meteen een seintje als er iets te melden valt, en je verliest geen tijd met kijken wanneer er niks is.

Concreet: je webshop stuurt een melding op het moment dat een klant een bestelling plaatst, je betaalprovider op het moment dat een betaling slaagt. Jouw systeem hoeft nergens om te vragen, de melding komt vanzelf binnen.

Hoe werkt een webhook?

Technisch stelt een webhook weinig voor, en dat is net de kracht. Er komen drie stappen aan te pas.

1. Je registreert een URL. In het bronsysteem (de webshop, de betaalprovider) geef je een adres op waar de meldingen naartoe moeten. Dat adres noemen we een endpoint. Je kiest er meteen bij op welke events je wil geabonneerd zijn.

2. Het bronsysteem stuurt een HTTP POST. Telkens zo'n event zich voordoet, stuurt het systeem een bericht naar jouw URL. Daarin zit een JSON-payload met de details: welk event het was, wanneer het gebeurde en de bijhorende data, zoals het bestelnummer en de bestelde artikelen.

3. Jouw kant bevestigt en verwerkt. Je endpoint antwoordt met een HTTP-statuscode in de 200-reeks om de ontvangst te bevestigen, en gaat daarna met de inhoud aan de slag.

Meer is het niet. Geen apart protocol, geen extra software. Alles wat een HTTP-request kan ontvangen, kan webhooks verwerken. In Power Automate heb je daarvoor zelfs geen eigen server nodig: de trigger "When an HTTP request is received" genereert een URL zodra je de flow opslaat, en elke POST naar die URL start je flow.

Webhook versus polling versus Change Data Capture

Wie systemen op elkaar wil laten reageren, heeft drie opties. Ze bestaan alle drie naast elkaar omdat ze elk een andere vraag beantwoorden.

Polling: jij blijft vragen

Bij polling vraagt jouw systeem op vaste tijdstippen of er al iets is: elke vijf minuten, elk uur, elke nacht. Simpel op te zetten en het werkt met elke API. De nadelen zie je pas op termijn: bijna al die aanvragen komen leeg terug, je zit met een wachttijd van maximaal één polling-interval, en bij korte intervallen bots je op de limieten van de API.

Webhook: de bron verwittigt jou

Een webhook keert de rollen om. Geen lege aanvragen meer en geen wachttijd: de melding vertrekt op het moment van het event. GitHub vat het in zijn eigen documentatie zo samen: webhooks vragen minder werk en minder resources dan een API pollen, en ze schalen beter. De voorwaarde is wel dat de bron webhooks aanbiedt en dat jij een endpoint hebt dat vanaf het internet bereikbaar is.

Change Data Capture: elke wijziging in de database

Change Data Capture (CDC) werkt nog een laag dieper. Waar een webhook één betekenisvol event doorgeeft, zoals een geplaatste bestelling, registreert CDC elke insert, update en delete in een database en stuurt die stroom door. Dat is het gereedschap om een data warehouse of lakehouse synchroon te houden met een operationeel systeem.

De vuistregel: wil je reageren op individuele gebeurtenissen in een applicatie, kies dan een webhook. Wil je volledige tabellen bijna realtime meekopiëren naar je dataplatform, kijk dan naar CDC. Is een verversing om de paar uur goed genoeg, of biedt de bron geen van beide aan, dan blijft polling een prima keuze.

Webhooks in de praktijk

Drie voorbeelden die we bij KMO's vaak tegenkomen:

• Nieuwe bestelling in de webshop. Shopify stuurt bij elke bestelling een orders/create-webhook. Die melding kan meteen een picklijst aanmaken in je magazijnsoftware, de bestelling doorzetten naar je ERP of een bericht posten in een Teams-kanaal.

• Geslaagde betaling. Stripe stuurt een event zodra een betaling rond is. Jouw systeem zet de factuur op betaald en start de levering, zonder dat iemand 's ochtends de betalingen moet overlopen.

• Een flow starten vanuit eender welke tool. Heeft een pakket geen kant-en-klare Power Automate-connector, maar wel webhook-ondersteuning? Dan plak je de URL van de HTTP-trigger in dat pakket en start je flow toch bij elk event.

Waar moet je op letten bij het gebruik van webhooks

Gemiste meldingen
Ligt jouw endpoint even plat, dan komt de melding niet aan. Goede afzenders proberen het opnieuw: Stripe blijft tot drie dagen lang opnieuw versturen, met steeds grotere tussenpauzes. Maar niet elke bron doet dat even lang of even netjes. Reken er dus nooit op dat elke melding gegarandeerd aankomt. Shopify raadt zelf aan om naast webhooks een periodieke controle via de API in te bouwen als vangnet.

Dubbele meldingen
Dezelfde melding kan twee keer binnenkomen, bijvoorbeeld wanneer jouw bevestiging de afzender niet bereikte en die het opnieuw probeert. Verwerk webhooks daarom idempotent: hou bij welke event-id's je al verwerkte en sla duplicaten over. Dat principe heet idempotentie, en het zorgt ervoor dat een bestelling nooit twee keer wordt aangemaakt.

Volgorde niet gegarandeerd
Stripe en Shopify zeggen het allebei expliciet: events komen niet noodzakelijk binnen in de volgorde waarin ze ontstonden. Een "bestelling gewijzigd" kan vóór "bestelling aangemaakt" binnenkomen. Gebruik daarom de timestamp in de payload, niet het moment van ontvangst.

Snel antwoorden
De afzender wacht niet eeuwig op je bevestiging. GitHub verwacht bijvoorbeeld binnen tien seconden een antwoord. Bevestig de ontvangst dus meteen en doe de eigenlijke verwerking daarna, in de achtergrond.

Beveiliging van je endpoint
Jouw webhook-URL staat open op het internet, dus iedereen die ze kent kan er berichten naartoe sturen. De meeste afzenders lossen dat op met een gedeeld secret: elke melding krijgt een handtekening mee (bij Stripe in de Stripe-Signature-header) die jij controleert voor je iets verwerkt. Behandel de URL zelf ook als een wachtwoord, zeker bij Power Automate, waar de toegangssleutel in de URL zit.

FAQ over webhooks

1. Heb ik een eigen server nodig om webhooks te ontvangen?
Nee. Tools zoals Power Automate, Azure Logic Apps of Zapier geven je een kant-en-klare URL die je in het bronsysteem plakt. De verwerking bouw je daarna visueel in je flow.

2. Wat als een pakket geen webhooks ondersteunt?
Dan val je terug op polling: op vaste tijdstippen via de API checken of er iets veranderd is. Minder direct, maar betrouwbaar, en voor veel processen ruim snel genoeg.

3. Zit alle data in de webhook zelf?
Niet altijd. Veel afzenders sturen bewust een beperkte payload, soms enkel een id. Jouw systeem haalt dan de volledige details op via een gewone API-call. Dat houdt de melding licht en je werkt altijd met de actuele versie van de data.

4. Is een webhook hetzelfde als een API?
Het is dezelfde techniek, HTTP-requests met JSON, maar in de omgekeerde richting. In de praktijk gebruik je ze samen: de webhook verwittigt je dat er iets gebeurd is, en via de API vraag je details op of voer je acties uit.

5. Hoe test ik een webhook?
Met de Stripe CLI stuur je events rechtstreeks door naar je eigen machine terwijl je ontwikkelt. In Power Automate zie je van elke run de ontvangen payload in de rungeschiedenis, zodat je snel ziet wat er precies binnenkwam.