Hoe werkt een webhook?
Je registreert een URL, het endpoint, bij het systeem dat de data heeft, en geeft aan welke events je interesseren. Als een van die events plaatsvindt, stuurt dat systeem een HTTP POST naar je endpoint met een payload die beschrijft wat er gebeurde, meestal in JSON. Je server leest de payload, doet zijn werk en geeft een 2xx-status terug om de ontvangst te bevestigen. Er was geen request van jou nodig om het in gang te zetten: de bron kwam zelf in actie. De meeste aanbieders ondertekenen elk request, zodat je kunt controleren of het echt van hen komt.
Webhook vs. API-polling: wat is het verschil?
Pollen is het pull-model: je code vraagt een API volgens een vast schema ‘is er iets nieuws?’, of er nu iets is veranderd of niet. Een webhook is het push-model: de bron roept jou alleen aan als er iets te melden is. Bij pollen zijn de meeste requests verspild en zit er vertraging tussen het event en je reactie; webhooks leveren binnen enkele seconden en blijven verder stil. De keerzijde is dat je endpoint openbaar bereikbaar moet zijn en pieken moet kunnen opvangen.
Hoe gebruiken engagementplatforms webhooks?
- Uitgaand: een webhooknode in een journey stuurt halverwege de flow een POST naar een extern systeem: Slack waarschuwen als een lead converteert, een status naar je CRM synchroniseren, een fulfilmentstap starten.
- Inkomend: een ontvanger neemt events van andere tools op. Een betaalprovider meldt een geslaagde betaling, een formuliertool geeft een nieuwe lead door, zodat profielen en journeys reageren zonder nachtelijke import.
- Door dit leidingwerk in twee richtingen kan een customer engagement platform in het midden van je stack staan. Gespecialiseerde afleverdiensten zoals Knock richten zich alleen op de uitgaande kant.
Waarom het ertoe doet voor een klein team
Een team van twee kan niet zitten pollen op wijzigingen, en cronjobs die om de paar minuten controleren, voegen zowel vertraging als kosten toe. Met webhooks reageert de ene tool op de andere zodra er iets gebeurt, zonder dat iemand hoeft te kijken. Twee waarschuwingen: omdat elke aanroeper naar een openbare URL kan POSTen, controleer je de handtekening op elk request en behandel je de body als onbetrouwbaar; en je logt de events die je verstuurt en ontvangt, zodat ze aansluiten op je trackingplan in plaats van een ongemeten zijkanaal te worden.