In het kort
Een webhook is een automatisch bericht dat software naar een afgesproken webadres stuurt zodra een gekozen gebeurtenis plaatsvindt. Denk aan een order die gereed wordt gemeld, waarna een ander systeem een taak voor de planner kan klaarzetten. De melding geeft een aanleiding om iets te doen. Of de taak werkelijk is aangemaakt, moet de ontvangende koppeling afzonderlijk controleren. Een webhook regelt dus geen volledige synchronisatie en geeft op zichzelf geen garantie dat je bedrijfsproces goed is afgerond.
Wat betekent webhook en wat is een webhook-URL?
Bij een webhook spreken twee toepassingen af waar een gebeurtenismelding naartoe mag. Het ontvangstadres heet vaak de webhook-URL of het endpoint. In de webhook-uitleg van GitHub staat het principe helder beschreven: je meldt je aan voor bepaalde gebeurtenissen, waarna het systeem bij zo’n gebeurtenis een HTTP-verzoek naar het opgegeven adres stuurt. Dat verzoek bevat gegevens waarmee de ontvanger kan bepalen wat er is gebeurd. De precieze inhoud verschilt per aanbieder en gebeurtenistype.
De URL is geen gewone pagina die een medewerker steeds moet openen. Er luistert software die het bericht controleert en afhandelt. Alleen een adres invullen is daarom onvoldoende: iemand moet de ontvangst, de beveiliging en de vervolgstappen inrichten. Vraag bij een leverancier welk systeem de melding verstuurt, welk systeem haar ontvangt en wie verantwoordelijk is als die ontvangst of verwerking mislukt. Zo blijft het technische adres verbonden aan een duidelijke werkafspraak.
Hoe werkt een webhook, van gebeurtenis tot vervolgwerk?
De route begint met een gebeurtenis in het bronsysteem. Een order krijgt bijvoorbeeld de status gereed voor planning. Het systeem stelt een bericht samen met een gebeurtenistype en beschikbare verwijzingen, zoals het ordernummer. Vervolgens probeert het dit bericht bij de afgesproken ontvanger af te leveren. Niet ieder pakket kan voor elke status een webhook sturen. Controleer daarom de ondersteunde gebeurtenissen voordat je het hele proces op één gewenste melding baseert.
De ontvanger controleert eerst of het bericht geldig is en of deze gebeurtenis verwerkt mag worden. Daarna kan hij het vervolgwerk vastleggen. Bij een verwerking met een wachtrij neemt die wachtrij de gecontroleerde opdracht over; een aparte verwerkingsstap maakt vervolgens de taak aan. Spreek af dat een positieve ontvangstbevestiging pas wordt gegeven nadat het bericht veilig is vastgelegd of het afgesproken werk is uitgevoerd. Anders kan een melding na bevestiging alsnog verdwijnen zonder zichtbare uitkomst.
Houd drie zaken uit elkaar: de gebeurtenis bestaat, het bericht is ontvangen en de gewenste zakelijke handeling is gelukt. Een technisch succesantwoord kan alleen de ontvangst bevestigen. De planner heeft daar weinig aan als de taak ontbreekt. Bewaar daarom een verwijzing naar het oorspronkelijke bericht en naar de aangemaakte taak, plus een zichtbare verwerkingsstatus. Die combinatie maakt het mogelijk om een incident later gericht te onderzoeken.
Wat is het verschil tussen een webhook, een API en polling?
Een webhook is vooral een manier om een gebeurtenis door te geven. Een API biedt functies waarmee software bijvoorbeeld gegevens kan opvragen of een record kan aanpassen. Ze kunnen samenwerken: de webhook meldt dat order ORD-237 is veranderd, waarna de ontvanger via een API de benodigde ordergegevens opvraagt. De gids over API-koppelingen legt de beschikbare functies en het verzoek met antwoord verder uit. Een webhook en een API zijn dus geen keuze waarbij je altijd één van beide moet uitsluiten.
Bij polling vraagt een koppeling op vaste momenten zelf of er iets is veranderd. Bij een webhook komt het initiatief voor de melding van het bronsysteem. Een webhook kan daardoor sneller op een gebeurtenis reageren, maar belooft geen vaste verwerkingstijd. Polling kan passend zijn wanneer updates minder haast hebben of het pakket geen geschikte gebeurtenismelding biedt. Ook een combinatie kan nuttig zijn: meldingen starten het dagelijkse werk, terwijl een aanvullende controle achteraf ontbrekende uitkomsten opspoort.
Een fictief voorbeeld: één order, één taak voor de planner
Stel dat een groothandel order ORD-237 gereedmeldt. Het ordersysteem verstuurt gebeurtenis EVT-81 naar de ontvangende koppeling. De gewenste uitkomst is één taak voor de planner, met de juiste orderverwijzing en een eigenaar. Dit is een fictief uitlegvoorbeeld; de nummers zijn geen echte klantgegevens. Het bericht mag de planner helpen om werk te starten, maar mag niet stilzwijgend betekenen dat goederen al zijn verzonden of dat een klant een bevestiging heeft ontvangen.
De koppeling bewaart welk werk bij EVT-81 hoort en legt bijvoorbeeld taak TAAK-52 vast. In de controleweergave moet terug te vinden zijn dat ORD-237 naar deze taak verwijst. Ontbreekt een verplicht gegeven, dan krijgt de verwerking een zichtbare fout of controleopdracht. Maak vooraf duidelijk wie die oppakt. Bij een koppeling met klantsoftware helpt het om de afspraken voor een CRM-integratie erbij te nemen: welk systeem blijft leidend en wie mag de informatie aanpassen?
Kunnen webhooks dubbel of in een andere volgorde aankomen?
Ja, dat moet je bij het ontwerp onderzoeken. Stripe beschrijft in zijn webhookdocumentatie dat dezelfde gebeurtenis meerdere keren kan worden afgeleverd en dat gebeurtenissen niet gegarandeerd in hun aanmaakvolgorde aankomen. Dit zijn eigenschappen van die aanbieder, geen universeel contract voor iedere webhook. Controleer de regels van jouw systemen. Een melding over een latere orderstatus kan bijvoorbeeld eerder verwerkt worden dan een ouder bericht. De koppeling mag daardoor een actuele status niet blind terugzetten.
Laat een herhaalde levering van EVT-81 niet nog een plannertaak maken. Daarvoor moet de verwerking de gebeurtenis of de zakelijke actie betrouwbaar herkennen en gelijktijdige pogingen veilig afhandelen. Alleen eerst een lijstje lezen en daarna een taak maken kan fout gaan wanneer twee pogingen tegelijk starten. Bespreek met de bouwer hoe één verwerking het werk mag claimen, hoe het resultaat wordt bewaard en hoe een mislukte poging later kan worden hervat zonder dubbel effect.
Een uniek gebeurtenisnummer helpt, maar beantwoordt niet elke vraag. Twee verschillende gebeurtenissen kunnen soms dezelfde zakelijke handeling voorstellen. Bepaal daarom ook op order- en actieniveau wanneer er al een taak bestaat. Gebruik daarnaast een duidelijke regel voor verouderde meldingen: bijvoorbeeld de actuele orderstatus opnieuw opvragen voordat de planning verandert. Welke regel klopt, hangt af van de gegevens en mogelijkheden van het pakket; een tijdstempel alleen bewijst niet altijd welke verwerking leidend moet zijn.
Wat gebeurt er bij een storing of gemiste melding?
Herhaalgedrag verschilt per aanbieder. Sommige systemen proberen een mislukte aflevering opnieuw, maar de duur, het aantal pogingen en de herstelmogelijkheden moet je in hun documentatie controleren. Als de melding wel is ontvangen maar de taak later mislukt, ziet de verzender die interne fout mogelijk niet. Je eigen koppeling moet daarom onafgerond werk zichtbaar maken, waar passend veilig opnieuw proberen en een verantwoordelijke waarschuwen wanneer dat niet helpt.
Laat de leverancier zowel een ontvangststoring als een verwerkingsstoring demonstreren. In het eerste geval is de ontvanger tijdelijk onbereikbaar. In het tweede geval is het bericht veilig binnen, maar lukt het maken van TAAK-52 niet. Vraag hoe het werk na herstel terugkomt en hoe zichtbaar blijft dat ORD-237 nog aandacht vraagt. Een periodieke vergelijking tussen gereedgemelde orders en bestaande taken kan als aanvullende controle dienen, wanneer de bron daarvoor voldoende gegevens beschikbaar stelt.
Hoe beveilig je de ontvangst van webhooks?
Een bekend ontvangstadres bewijst niet wie een bericht heeft gestuurd. Gebruik de beveiligingsmethode die de aanbieder ondersteunt en controleer die vóór zakelijke verwerking. De webhookrichtlijnen van GitHub adviseren onder meer HTTPS, verificatie met een webhookgeheim en het beperken van de gebeurtenissen waarop je je abonneert. Stripe beschrijft verificatie van de ondertekende berichtinhoud. Die controle beschermt de herkomst en integriteit; HTTPS alleen maakt een willekeurig ontvangen bericht nog niet betrouwbaar.
Zet geen wachtwoorden, API-sleutels of andere geheimen in de webhook-URL. Bewaar technische geheimen in daarvoor bedoelde beschermde opslag en laat ze niet in foutmeldingen of gewone logboeken verschijnen. Beperk ook de gegevens die het bericht en de registratie bevatten tot wat voor de verwerking nodig is. Spreek af wie de toegang beheert, hoe geheimen kunnen worden vervangen en wie onderzoekt of ongeldige berichten terecht zijn afgewezen. Een testomgeving hoort hiervoor fictieve gegevens te gebruiken.
Vier proeven voordat je de koppeling in gebruik neemt
Begin met een normale gebeurtenis en zoek de uitkomst in het doelsysteem op: één juiste taak met een bruikbare orderverwijzing. Lever daarna hetzelfde bericht nogmaals aan in de testomgeving. Controleer dat geen tweede taak verschijnt en dat de oorspronkelijke taak terug te vinden blijft. Alleen een groen antwoord op de webhook-URL is voor deze proef onvoldoende. De gewenste uitkomst ligt bij de planner, niet alleen in het technische afleverlogboek.
Onderbreek vervolgens de ontvangst of de verwerking en toon het herstel, inclusief de zichtbare fout en de verantwoordelijke. Bied ten slotte een oudere en een nieuwere gebeurtenis in omgekeerde volgorde aan. Controleer dat de afgesproken actuele status behouden blijft. Noteer bij elke proef de invoer, het verwachte resultaat en het echte bewijs. Neem ook een ongeldige herkomstcontrole mee: zo’n bericht mag geen zakelijke handeling starten. Deze voorbeelden zijn een basis; risicovolle acties vragen aanvullende controles.
Wanneer is een webhook een passende keuze?
Een webhook past wanneer een ondersteunde gebeurtenis een duidelijke vervolgstap moet starten en je de ontvangst en verwerking kunt beheren. Voor een incidentele gegevensvraag is een losse API-aanvraag soms eenvoudiger. Voor een dagelijkse controle kan periodiek ophalen voldoende zijn. Begin bij het werkproces en de gewenste snelheid, niet bij de techniek. De uitleg over procesautomatisering helpt om de aanleiding, eigenaar en uitkomst van die eerste stap concreet te maken.
Neem voor een gesprek met Softora de gebruikte pakketten, de gewenste gebeurtenis en een fictief bronrecord mee. Beschrijf welke uitkomst een medewerker daarna moet zien en wie fouten herstelt. Vraag ook welke kosten of beperkingen gelden voor webhook- en API-toegang bij de pakketleveranciers. Bij bedrijfssoftware op maat kan dan gericht worden onderzocht hoe de eerste overdracht aansluit op je bestaande systemen, zonder meteen het hele proces opnieuw te bouwen.
Over deze uitleg
Deze uitleg is opgesteld door Softora met hulp van AI. De technische claims zijn gecontroleerd aan de genoemde originele documentatie, geraadpleegd op 15 oktober 2026. De groothandel, order, gebeurtenis en taak zijn fictief. De keuzevragen, acceptatieproeven en diagrammen vormen een eigen praktische uitwerking; de hoofdillustratie is met AI gemaakt.
