Webhooks zijn geautomatiseerde berichten die door een applicatie worden verzonden wanneer een specifieke gebeurtenis plaatsvindt. Ze stellen verschillende systemen in staat om direct met elkaar te communiceren zonder handmatige tussenkomst. Een webhook is in essentie een HTTP-callback: een HTTP POST-verzoek dat automatisch wordt verzonden naar een vooraf geconfigureerde URL wanneer een bepaalde gebeurtenis optreedt. Deze gebeurtenissen kunnen bijvoorbeeld zijn: een nieuwe bestelling in een webshop, een nieuw contactformulier dat wordt ingevuld, een betaling die wordt verwerkt, een wijziging in voorraadniveaus of een update in een CRM-systeem. Webhooks zijn bijzonder nuttig wanneer je wilt dat systemen automatisch reageren op gebeurtenissen in andere systemen, zonder constant te hoeven controleren of er iets is veranderd.
Het proces van een webhook verloopt volgens een aantal basisstappen:
1. Ten eerste vindt de configuratie plaats. Een applicatie (de 'verzender') biedt de mogelijkheid om webhooks in te stellen. Je geeft de URL op waar de webhooks/je berichten naartoe moeten worden gestuurd en selecteert welke gebeurtenissen een bericht moeten triggeren.
2. Daarna volgt de registratie. Je registreert de webhook door deze instellingen op te slaan in de verzendende applicatie.
3. Vervolgens is er de gebeurtenis detectie. Wanneer een relevante gebeurtenis plaatsvindt in de verzendende applicatie, wordt de webhook getriggerd.
4. Dan komt de verzending. De applicatie stuurt automatisch een HTTP POST-verzoek naar de geconfigureerde URL met informatie over de gebeurtenis in JSON- of XML-formaat.
5. Hierna volgt ontvangst en verwerking. De ontvangende server (de 'ontvanger') krijgt het bericht en verwerkt de gegevens volgens de eigen logica.
6. Tot slot is er de bevestiging. De ontvanger stuurt meestal een HTTP-statuscode terug om te bevestigen dat het bericht is ontvangen.
Ter illustratie: als een klant een bestelling plaatst in een Shopify-webshop, kan Shopify een webhook-bericht sturen naar je eigen server met alle details van de bestelling. Je server kan deze gegevens dan verwerken, bijvoorbeeld door ze toe te voegen aan een CRM-systeem of door ze te gebruiken voor conversie-tracking. Voor meer informatie over de werking van webhooks, verwijzen we je naar het volgende artikel.
De technologie achter webhooks is gratis te gebruiken, het concept is open en er zijn geen licentiekosten aan verbonden. Het is simpelweg een communicatiemethode die gebruikt maakt van standaard HTTP-protocollen. Wel kunnen er kosten verbonden zijn aan de implementatie en ontwikkeling van webhook-functionaliteiten. Ook de serverinfrastructuur die nodig is om webhooks te verwerken en dataverkeer en servertijd bij grote volumes aan webhook-berichten kunnen kosten met zich meebrengen. De meeste platforms en diensten zoals Shopify, WooCommerce, Stripe, PayPal, en GitHub bieden webhooks aan als onderdeel van hun dienstverlening zonder extra kosten. Sommige diensten kunnen echter limieten stellen aan het aantal webhooks of het volume aan berichten binnen bepaalde abonnementen. Lees verder over de kosten van webhooks.
Webhooks en API's zijn gerelateerde concepten, maar werken wezenlijk anders. Een API (Application Programming Interface) werkt volgens het "pull"-principe. Je systeem vraagt actief om gegevens. Je moet regelmatig controleren of er nieuwe informatie beschikbaar is. Jij initieert de communicatie. Een webhook daarentegen werkt volgens het "push"-principe. Gegevens worden automatisch verzonden wanneer er iets gebeurt. Je hoeft niet te controleren of er nieuwe informatie is. De externe applicatie initieert de communicatie. Een webhook kan worden gezien als een "omgekeerde API" of een specifiek type API-implementatie waarbij de communicatierichting is omgedraaid. In plaats van dat jij voortdurend vraagt "Is er iets nieuws?", vertelt de webhook je "Hé, er is iets nieuws gebeurd!". Lees hier verder over het verschil tussen webhooks en een API.
Bij AdPage gebruiken wij webhooks specifiek voor conversie-tracking in e-commerce. We zetten webhooks in om vanuit de backend van een webshop een HTTP-verzoek naar een server container te sturen op het moment dat er een order wordt aangemaakt. Dit is een aanzienlijke verbetering ten opzichte van traditionele meetmethoden die vertrouwen op het laden van de bedankpagina. Sommige concurrenten stellen webhooks in vanuit deze bedankpagina, maar dit en de standaard tracking via de frontend van een webshop heeft belangrijke nadelen:
1. Allereerst zijn er meetproblemen. Niet alle gebruikers komen op de bedankpagina terecht, waardoor je de aankoop-conversie niet kan meten.
2. Daarnaast zijn er attributieproblemen. Het correct toewijzen van conversies aan de juiste gebruiker en bron is lastig bij metingen via de bedankpagina. Want als een bezoeker de gehele klantreis in bijvoorbeeld de Google Chrome browser doorloopt en hun betaalapplicatie de standaardbrowser opent, wat kan verschillen van de Google Chrome browser, zal de aankoop-conversie niet aan de juiste oorspronkelijke bron toegewezen worden.
3. Ten slotte zijn er vertragingen. De bedankpagina wordt pas geladen nadat de bestelling volledig is verwerkt. Ook kan je de aankoop pas meten op het moment dat de gehele pagina en alle scripts geladen zijn.
Door webhooks direct vanuit de backend te implementeren, kunnen we elke order registreren, ongeacht gebruikersgedrag na de bestelling. We ontvangen alle relevante ordergegevens voor nauwkeurige attributie en krijgen real-time informatie over conversies. Ook wanneer je klant de cookies geweigerd heeft, kan je alsnog de eCommerce data doorsturen naar GA4 maar zal je geen PII (persoonlijk identificeerbare informatie) meesturen. Voor meer informatie over AdPage webhooks verwijzen we je naar dit blog-artikel.
Webhooks hebben ook nadelen. Als de ontvangende server offline is, gaat informatie verloren zonder herstelmogelijkheid. De beveiliging is een uitdaging omdat endpoints openbaar bereikbaar moeten zijn. Het oplossen van problemen is lastig door de asynchrone communicatie, waardoor fouten moeilijk te vinden zijn. Webhooks werken alleen met een stabiele internetverbinding en kunnen bij veel verkeer vertragen. Ze bieden weinig mogelijkheden voor ingewikkelde zoekopdrachten of filteropties. Voor ontwikkelaars betekent dit extra werk voor foutafhandeling, herhaalpogingen en beveiliging, terwijl er vaak weinig documentatie beschikbaar is. Vandaar dat het belangrijk is dat je met een partij werkt die deze moeilijkheden al opgelost hebben en alles voor je monitoren.
Webhooks maken gebruik van het HTTP-protocol, meestal in de vorm van HTTP POST-verzoeken. De verzendende applicatie stuurt gegevens via dit protocol naar een vooraf ingestelde URL. De informatie wordt vaak in JSON- of XML-formaat verzonden, afhankelijk van de voorkeur van de service die de webhook aanbiedt. De ontvangende server bevestigt de ontvangst met een HTTP-statuscode zoals 200 OK. Sommige implementaties ondersteunen ook beveiligde communicatie via HTTPS voor betere gegevensbeveiliging.
Een endpoint is een URL-toegangspunt binnen een API dat verzoeken ontvangt en verwerkt. Het fungeert als bestemming waar systemen naartoe kunnen communiceren. Een webhook daarentegen is een specifieke API-URL die realtime-informatie of statuswijzigingen ontvangt wanneer een bepaalde gebeurtenis plaatsvindt in een andere toepassing. Het belangrijkste verschil zit in het gedrag: endpoints wachten passief op verzoeken die naar hen worden gestuurd, terwijl webhooks actief data versturen naar een vooraf ingesteld adres zodra een trigger plaatsvindt.
Een hook URL is het specifieke webadres waarnaar webhook-berichten worden verzonden. Deze URL fungeert als het bestemmingspunt waar de verzendende applicatie automatisch data naartoe stuurt wanneer een bepaalde gebeurtenis plaatsvindt. De hook URL moet vooraf worden geconfigureerd in de verzendende applicatie en moet bereikbaar zijn via het internet.