Webhooks uitgelegd voor niet-techneuten

Je gebruikt waarschijnlijk al een handvol tools naast elkaar: een webshop, een agenda, een mailprogramma, misschien een boekhoudpakket en een CRM. Elk van die tools doet zijn ding prima. Het probleem zit ertussen. Een nieuwe bestelling in je webshop weet niets van je agenda. Je agenda weet niets van je boekhouding. En dus zit jij ertussen, gegevens overtikkend van het ene scherm naar het andere.

Webhooks zijn de oplossing voor precies dat probleem. Het woord klinkt technisch, maar het idee is doodsimpel. In deze gids leg ik in gewone taal uit wat een webhook is, waarom het de lijm is tussen je tools, hoe het er in de praktijk uitziet, en waar het misgaat als je het niet goed bouwt. Geen voorkennis nodig.

Wat is een webhook, in gewone taal

Stel je voor dat je iets bestelt bij een webshop. Je kunt op twee manieren te weten komen of je pakket onderweg is.

De eerste manier: je belt elke tien minuten naar de bezorgdienst om te vragen of er al nieuws is. Vermoeiend, en negen van de tien keer is het antwoord "nee, nog niks". Dat heet in techniektaal polling: steeds opnieuw vragen of er iets veranderd is.

De tweede manier: je geeft je telefoonnummer af en zegt "bel me zodra het pakket vertrekt". Je hoeft niets te doen. Op het moment dat er iets gebeurt, krijg je vanzelf bericht. Dat, in essentie, is een webhook.

Een webhook is dus een automatisch berichtje dat de ene tool naar de andere stuurt op het moment dat er iets gebeurt. Niet vragen, maar geduwd krijgen. De ene tool zegt tegen de andere: "er is zojuist een nieuwe bestelling binnengekomen, hier zijn de details, doe ermee wat je moet doen."

Dat berichtje is klein en gestructureerd. Het bevat precies wat er gebeurd is: wie de klant is, wat er besteld is, welk bedrag erbij hoort. De ontvangende tool leest het en gaat aan de slag.

Waarom het de lijm is tussen je tools

Bijna elke moderne tool kan webhooks versturen, ontvangen, of allebei. Daarmee worden ze de verbindingsstof tussen systemen die elkaar van zichzelf niet kennen.

Het mooie is dat het in realtime gebeurt. Geen handmatige export, geen "ik draai vanavond wel even een batch". Het moment dat er iets gebeurt in tool A, weet tool B het. Dat verschil voel je vooral als het druk wordt.

En het werkt twee kanten op. Je webshop kan een webhook sturen naar je boekhouding, je agenda naar je mail, je betaalprovider naar je voorraadsysteem. Door deze berichtjes aan elkaar te knopen, bouw je een keten waarin gegevens vanzelf doorstromen, zonder dat jij ertussen zit.

Dat is precies wat een integratie onder de motorkap vaak is: een slimme afhandeling van webhooks. Op de integraties zie je per tool wat er bij zo'n koppeling allemaal wordt uitgewisseld. De webhook is daarbij telkens het startschot.

Een concreet praktijkvoorbeeld

Genoeg theorie. Laten we een echte situatie nemen die je waarschijnlijk herkent.

Je hebt een webshop. Iemand plaatst een bestelling voor een dienst waar een afspraak bij hoort, denk aan een fotoshoot, een adviesgesprek of een installatie aan huis. Zonder automatisering gebeurt er dan dit: jij krijgt een mailtje van de webshop, je leest het, je pakt je agenda erbij, je plant een afspraak in, je stuurt de klant een bevestiging, en je tikt de gegevens over in je administratie. Vier of vijf handmatige stappen, voor elke bestelling.

Met webhooks ziet diezelfde flow er zo uit:

1. De trigger. De klant rekent af. De webshop stuurt een webhook met de boodschap "nieuwe betaalde bestelling", inclusief de naam van de klant, het e-mailadres, de gekozen dienst en het tijdslot.
2. De boeking. Die webhook komt binnen bij een koppeling. Die kijkt naar het gekozen tijdslot en zet automatisch een afspraak in je agenda. Geen dubbele boekingen, want de koppeling checkt of het slot nog vrij is.
3. De melding. Tegelijk gaat er een nette bevestigingsmail naar de klant, en krijg jij een seintje in je team-chat of mailbox: "nieuwe boeking, dit en dat, op die datum."
4. De administratie. En als laatste belandt de bestelling als factuurregel in je boekhouding, met de juiste btw en het juiste bedrag.

Vijf handmatige stappen, teruggebracht tot nul. Jij hoeft alleen nog op te dagen voor de afspraak. De webhook van de webshop was het ene zetje dat de hele keten in beweging bracht.

In de praktijk koppel je hiervoor gereedschap als Shopify of WooCommerce aan een agenda-tool zoals Calendly, een mailkanaal zoals Gmail en je boekhouding in Moneybird. Elk van die stappen wordt aangestuurd door een webhook die op het juiste moment afgaat.

Waar het misgaat

Webhooks klinken simpel, en het basisidee is dat ook. Maar tussen "het werkt op een rustige dinsdag" en "het werkt ook tijdens je drukste week" zit een wereld van details. Dit zijn de drie plekken waar het in de praktijk fout loopt.

Dubbele events

Dit is de meest voorkomende valkuil. Webhooks worden soms twee keer afgeleverd. Dat is geen bug, dat is gewoon hoe het internet werkt: de verzendende tool weet niet zeker of het berichtje is aangekomen, dus stuurt hij het voor de zekerheid nog een keer.

Het gevolg, als je het niet afvangt: twee afspraken voor één bestelling, twee bevestigingsmails, twee facturen. De oplossing heet idempotentie, een lelijk woord voor een eenvoudig principe. Elk event krijgt een uniek kenmerk en de koppeling onthoudt welke kenmerken hij al verwerkt heeft. Komt hetzelfde event nog eens binnen, dan doet de koppeling niets. Klein detail, voorkomt een hoop opruimwerk.

Retries en mislukte aflevering

De andere kant van dezelfde medaille. Wat als de ontvangende tool er even uit ligt, bijvoorbeeld door onderhoud of een storing? Dan komt de webhook niet aan, en is de bestelling weg. Het event wordt immers maar één keer veroorzaakt.

Goede systemen lossen dit op met retries: lukt de aflevering niet, dan probeert de verzender het even later opnieuw, en daarna nog eens, met steeds grotere tussenpozen. Aan de ontvangende kant moet je dan wel netjes laten weten of je een bericht goed hebt verwerkt. En voor de zekerheid wil je ergens vastleggen welke events binnenkwamen, zodat je nooit stilletjes een bestelling verliest die je pas weken later mist.

Beveiliging

Een webhook is in feite een deurtje in je systeem waar van buitenaf berichtjes naar binnen komen. En een deurtje dat openstaat, kan ook door de verkeerde worden gebruikt. Als iemand doorheeft op welk adres jouw koppeling luistert, kan diegene nepberichten sturen: een verzonnen bestelling, een valse betaling, een afspraak die nooit geplaatst is.

Daarom horen webhooks ondertekend te zijn. De verzendende tool zet een soort digitaal zegel op elk bericht, en jouw koppeling controleert dat zegel voordat hij iets doet. Klopt het zegel niet, dan gaat het bericht de prullenbak in. Zonder die controle vertrouw je blind alles wat er binnenkomt, en dat is vragen om problemen. Dit is precies het soort ding dat een snelle no-code-koppeling vaak overslaat, en dat je pas merkt als het te laat is.

Kant-en-klaar of maatwerk?

Niet elke situatie vraagt om maatwerk. Eerlijk advies: begin niet groter dan nodig.

Voor veelvoorkomende koppelingen tussen bekende tools bestaan prima kant-en-klare oplossingen en koppel-apps. Verkoop je standaardproducten aan Nederlandse klanten, en past je flow binnen wat zo'n app aanbiedt, dan gebruiken. Ik bouw niets dat al bestaat en goed genoeg is.

Maatwerk loont zodra je eigen logica nodig hebt: meerdere tools die in een specifieke volgorde moeten reageren, uitzonderingen die netjes afgehandeld moeten worden, of een keten waar net die ene stap tussen zit die geen enkele standaard-app kan. En vooral: zodra het misgaan dat ik hierboven beschreef je echt geld of klanten kost. Dubbele facturen, gemiste bestellingen of een lek in je beveiliging zijn geen details als ze een keer fout gaan op een drukke dag.

Met slim werken, loont hard werken

Een webhook is niets meer dan een tool die op het juiste moment "hé, dit is er gebeurd" roept naar een andere tool. Maar door die berichtjes slim aan elkaar te knopen, verdwijnt een hele berg overtypwerk uit je dag. Het werk gebeurt nog steeds, alleen niet meer door jou.