Wat is een webhook en wanneer is hij nodig?

Om 21:14 bestelt een klant in de webshop. Het ERP, waar de voorraad en de planning leven, weet op dat moment van niets, en er is niemand op kantoor om het over te typen. De vraag hoe het ERP erachter komt, is de kernvraag van elke koppeling, en er bestaan maar twee antwoorden: het ERP kan laten vragen of er iets is, of de webshop kan het komen vertellen. Dat tweede heet een webhook.

De vraag

Wat is een webhook, en wanneer heeft u hem nodig?

Het antwoord

Bij de eerste manier, pollen, vraagt de koppeling met vaste tussenpozen aan de webshop: zijn er nieuwe orders? Meestal is het antwoord nee, en over een uur zijn dat twaalf vragen voor niets. Het is de brievenbus die u elke tien minuten controleert omdat u een pakje verwacht.

Een webhook draait de richting om. U geeft de webshop één keer een adres, en zodra er iets gebeurt waarop u zich hebt geabonneerd, een nieuwe order, een betaling, een annulering, stuurt de webshop zelf een bericht naar dat adres, met de gegevens erbij. GitHub, dat er veel mee werkt, definieert het zo: "Webhooks let you subscribe to events happening in a software system and automatically receive a delivery of data to your server whenever those events occur." De brievenbus heeft een deurbel gekregen.

Het verschil merkt u op twee plekken. De eerste is tijd. Een poll loopt per definitie achter: gemiddeld een half interval, in het slechtste geval een heel. En dat interval is niet altijd van u; bij Power Automate bepaalt bijvoorbeeld de licentie hoe vaak een pollingtrigger mag kijken, op een Office 365-plan hooguit elke vijf minuten. Een webhook komt binnen zodra het gebeurt. Voor een order die morgen pas de deur uit gaat, maakt dat niets uit; voor een betaling die een levering vrijgeeft wel.

De tweede plek is het tellen. Veel pakketten begrenzen het aantal aanroepen per dag, en een poll die niets vindt, telt gewoon mee. Twaalf keer per uur vragen is bijna driehonderd aanroepen per dag voor een webshop die misschien twintig orders doet. GitHub zegt het in dezelfde uitleg nuchter: wie informatie maar af en toe nodig heeft, kan beter gewoon vragen; wie veel bronnen in de gaten houdt of direct wil reageren, is met webhooks beter af.

Waarom dan niet altijd een webhook? Om drie redenen die in offertes zelden worden uitgesproken. Ten eerste moet er aan uw kant iets zijn dat het bericht aanneemt: een adres dat altijd bereikbaar is, dus een draaiende omgeving, niet een laptop die om zes uur dichtklapt. Ten tweede is een gemiste bel een stil gat: ligt uw kant er tien minuten uit, dan is het bericht geweest, en of de afzender het opnieuw probeert verschilt per pakket. Een koppeling die alleen op de bel vertrouwt, kan stilvallen zonder dat iemand het merkt; daarom combineren degelijke koppelingen de bel met een periodieke controle die kijkt of er niets gemist is. Het is de deurbel plus één keer per dag toch even in de brievenbus kijken. En ten derde: niet elk pakket kán bellen. Webhooks moeten door de leverancier zijn ingebouwd, en veel oudere pakketten hebben hooguit een zijdeur, geen bel. Dan is pollen geen tweede keus maar de enige.

Voor de meeste administratieve koppelingen is de eerlijke conclusie dat pollen volstaat. Orders die elk kwartier worden opgehaald, facturen die elke nacht worden gelezen: niemand merkt het verschil met direct. De webhook wordt het waard waar seconden tellen of waar de aantallen groot worden, en dan verschuift de aandacht meteen naar de saaie kant ervan: wie merkt het als de bel een dag niet rinkelt?

De vraag aan de leverancier

Wie een koppeling laat bouwen of kiezen, kan dit met één vraag scherp krijgen: kan uw pakket mijn systeem roepen als er iets gebeurt, of moet mijn systeem blijven vragen? En zo ja, wat doet u als mijn kant even niet bereikbaar was? Het eerste antwoord zegt wat er technisch kan. Het tweede zegt of de bouwer heeft nagedacht over de dag dat het misgaat, en dat antwoord voorspelt meer over de koppeling dan de snelheid ooit doet.