Een webhook is een mechanisme waarmee een applicatie automatisch een melding stuurt naar een andere applicatie op het moment dat een specifieke gebeurtenis plaatsvindt. In tegenstelling tot de traditionele aanpak waarbij jouw systeem periodiek vraagt of er nieuws is (polling), draaien webhooks dit om: de bronapp stuurt actief een HTTP-verzoek naar jouw systeem zodra er iets relevants gebeurt. Dit maakt webhooks snel, efficiënt en ideaal voor realtime integraties. Je treft ze aan in betalingssystemen, CRM-platformen, Git-platforms en talloze andere diensten die gebeurtenissen naar externe systemen willen doorgeven.
Hoe werken webhooks?
De werking van een webhook is eenvoudig. Jij registreert een URL bij de bronapp — dit is het endpoint van jouw server dat verzoeken kan ontvangen. Zodra de gedefinieerde gebeurtenis plaatsvindt, stuurt de bronapp een HTTP POST-verzoek naar die URL met informatie over de gebeurtenis in de request body, doorgaans in JSON-formaat.
Jouw server ontvangt het verzoek, verwerkt de data en stuurt een HTTP 200-statuscode terug als bevestiging. Als de bronapp geen 200 ontvangt (bijvoorbeeld door een time-out of serverfout), probeert ze het verzoek na enige tijd opnieuw. Dit retry-mechanisme zorgt ervoor dat berichten niet verloren gaan bij tijdelijke storingen.
Webhooks versus polling
Bij polling vraagt jouw applicatie elke X seconden aan de bronapp of er nieuwe data is. Dit is inefficiënt: de meeste verzoeken leveren niets op, maar belasten wel de server en het netwerk. Hoe korter het interval, hoe groter de belasting; hoe langer het interval, hoe groter de vertraging.
Webhooks zijn event-driven: jouw server wordt alleen aangesproken als er daadwerkelijk iets is gebeurd. Dit is aanzienlijk efficiënter en levert realtime notificaties op zonder onnodige serverbelasting. Voor hoog-frequente events of grote volumes zijn webhooks de verreweg betere keuze.
Veelvoorkomende toepassingen van webhooks
Betaalplatformen zoals Stripe en Mollie gebruiken webhooks om betalingsbevestigingen te sturen. Zodra een betaling succesvol is verwerkt, stuurt het platform een webhook naar jouw systeem, dat vervolgens automatisch een bestelling kan activeren, een factuur versturen of een abonnement starten. Dit elimineert de noodzaak om periodiek te checken of een betaling is binnengekomen.
Git-platformen zoals GitHub en GitLab versturen webhooks bij elke push, pull request of comment. CI/CD-systemen luisteren naar deze webhooks om automatisch een build of testrun te starten zodra nieuwe code wordt gepusht. Dit is de basis van moderne continuous integration-workflows.
CRM- en marketingtools gebruiken webhooks om klantacties door te geven aan andere systemen. Als een klant een formulier invult op je website, kan de CRM via een webhook de e-mailmarketingdienst informeren om de klant toe te voegen aan een welkomstflow. Dit soort realtime datasynchronisatie zou met polling veel trager en complexer zijn.
Een webhook beveiligen
Omdat een webhook-endpoint publiek bereikbaar moet zijn, is beveiliging essentieel. De meest gebruikte methode is een signature verificatie: de bronapp stuurt een HMAC-handtekening mee in de request header, berekend op basis van de request body en een gedeeld geheim. Jouw server berekent dezelfde handtekening en vergelijkt deze; klopt het niet, dan verwijs je het verzoek.
Gebruik altijd HTTPS voor je webhook-endpoint om afluisteren te voorkomen. Voeg ook een IP-allowlist toe als de bronapp vaste IP-adressen gebruikt, en stel een timeout in voor de verwerking zodat je server niet lang bezet raakt door trage webhooks.
Webhook endpoints implementeren
Een eenvoudig webhook-endpoint is in elke taal en framework te bouwen. Het eindpunt luistert naar POST-verzoeken, valideert de handtekening, verwerkt de payload en retourneert snel een 200-status. De daadwerkelijke verwerking, zoals het aanpassen van een database of versturen van een e-mail, doe je bij voorkeur asynchroon via een job queue. Zo blijft de responstijd kort en verklein je de kans op time-outs.
Tools als ngrok zijn handig tijdens ontwikkeling: ze maken een tijdelijk publiek toegankelijk URL aan dat verzoeken doorstuurt naar je lokale server, zodat je webhooks kunt testen zonder een live server te hoeven deployen.
Conclusie
Webhooks zijn een eenvoudige maar krachtige manier om realtime integraties tussen applicaties te bouwen. Door te luisteren in plaats van continu te vragen, zijn ze efficiënter dan polling en leveren ze directere notificaties op. Of je nu betalingen verwerkt, CI/CD-pipelines triggert of klantdata synchroniseert, webhooks zijn de lijm tussen moderne applicaties. Zorg voor een goede beveiliging van je endpoints en verwerk payloads asynchroon voor een robuuste implementatie.
Veelgestelde vragen
Wat is het verschil tussen een webhook en een API?
Een API is een interface waarmee jouw applicatie actief data opvraagt of acties uitvoert bij een andere dienst (pull). Een webhook is een notificatiemechanisme waarbij de andere dienst jouw applicatie actief informeert bij een gebeurtenis (push). Ze zijn complementair: veel diensten bieden zowel een API als webhooks aan voor verschillende use cases.
Wat gebeurt er als mijn webhook-endpoint niet bereikbaar is?
De meeste webhook-aanbieders implementeren een retry-mechanisme: als het endpoint geen 200-statuscode retourneert, wordt het verzoek na een toenemend interval opnieuw geprobeerd (exponential backoff). Na een aantal mislukte pogingen, doorgaans 24 tot 72 uur later, wordt het verzoek definitief gestopt en ontvang je mogelijk een foutmelding.
Hoe test ik een webhook tijdens ontwikkeling?
Gebruik ngrok of een vergelijkbare tunneltool om een publiek URL te genereren dat verzoeken doorstuurt naar je lokale server. Veel platformen bieden ook een testfunctie in hun dashboard waarmee je handmatig een webhook kunt triggeren met een voorbeeldpayload.
Kan een webhook idempotent zijn?
Ja, en dat is sterk aanbevolen. Door elke webhook-payload te voorzien van een uniek ID en dit ID te controleren voor verwerking, voorkom je dat dubbele verzoeken (door retries) twee keer worden verwerkt. Sla verwerkte IDs op in je database en sla verzoeken met een al bekend ID over.
Hoe groot kan een webhook-payload zijn?
De maximale payload-grootte verschilt per aanbieder, maar is doorgaans beperkt tot enkele megabytes (1–10 MB). Webhooks zijn bedoeld voor event-notificaties, niet voor het overdragen van grote bestanden. Als je grote data wilt overdragen, stuur dan een webhook met een verwijzing (URL of ID) en haal de data vervolgens op via de API van de aanbieder.