Webhooks

Bij een API moet uw systeem meestal zelf om updates vragen (polling). Een webhook werkt andersom: het systeem stuurt de data automatisch naar u toe zodra er iets gebeurt. Dit is veel efficiënter voor real-time koppelingen tussen bijvoorbeeld een PIM en een webshop.

Webhooks zorgen ervoor dat wijzigingen in productinformatie direct worden doorgezet naar alle verkoopkanalen. Hierdoor voorkomt u dat er foutieve prijzen of verouderde specificaties op uw website staan, wat de betrouwbaarheid van uw webshop verhoogt.

Ja, mits correct geïmplementeerd. Door gebruik te maken van HTTPS en het verifiëren van een unieke 'secret key' of digitale handtekening, kunt u er zeker van zijn dat de data echt van uw PIM-systeem afkomstig is en niet van een onbevoegde bron.

Het is essentieel om een retry-mechanisme of een wachtrij (queue) in te stellen zodat data niet verloren gaat als de ontvangende server tijdelijk onbereikbaar is. De meeste systemen verwachten een 200 OK statuscode als bevestiging; wordt deze niet ontvangen, dan moet het bronsysteem de data met toenemende tussenpozen opnieuw proberen te verzenden.

Webhooks zijn de beste keuze wanneer real-time updates cruciaal zijn, zoals bij voorraadwijzigingen of de status van bestellingen. In tegenstelling tot polling, waarbij resources worden verbruikt zelfs als er geen wijzigingen zijn, worden webhooks alleen geactiveerd bij een daadwerkelijke gebeurtenis, wat veel efficiënter is voor dynamische webshops.

Ja, de meeste moderne PIM-systemen bieden de mogelijkheid om filters in te stellen zodat webhooks alleen afgaan bij wijzigingen in specifieke velden, zoals prijs of voorraad. Dit voorkomt dat je webshop wordt overspoeld met onnodige updates tijdens het bewerken van interne velden die niet relevant zijn voor de front-end.

Webhooks verlagen de serverbelasting doordat ze de noodzaak voor constante, herhalende verzoeken om nieuwe data wegnemen. In plaats van dat je webshop elke minuut het PIM-systeem bevraagt, stuurt het PIM-systeem alleen data wanneer er daadwerkelijk iets is veranderd, wat aanzienlijk bespaart op CPU-gebruik en bandbreedte.

Om webhooks te ontvangen, heb je drie basiszaken nodig: een bronsysteem dat webhooks ondersteunt, een unieke URL op je eigen server die als endpoint fungeert en de mogelijkheid om binnenkomende HTTP-berichten te verwerken. Je configureert de bron om data naar jouw URL te sturen bij specifieke gebeurtenissen, zoals een voorraadwijziging. Zodra het bronsysteem een bericht stuurt, moet jouw applicatie dit signaal opvangen, valideren en de gewenste actie uitvoeren in je eigen database om de informatie te synchroniseren.

Webhooks worden in webshops voor diverse processen ingezet. Een bekend voorbeeld is de statusupdate van een betaling; zodra een klant betaalt, stuurt de betaalprovider een webhook naar de webshop om de order direct op betaald te zetten. Ook bij voorraadbeheer zijn ze cruciaal. Verandert de voorraad in het magazijnsysteem, dan zorgt een webhook ervoor dat dit meteen in de webshop wordt bijgewerkt. Andere voorbeelden zijn het automatisch versturen van verzendbevestigingen of het real-time bijwerken van klantgegevens in een CRM-systeem.

Het beheer van webhooks is meestal een gedeelde verantwoordelijkheid tussen technisch beheerders en developers. De developer is verantwoordelijk voor het bouwen en onderhouden van het endpoint dat de data ontvangt. Een e-commerce manager of PIM-beheerder bepaalt echter welke gebeurtenissen een trigger moeten vormen, zoals prijsveranderingen of nieuwe productcreaties. Zij monitoren vaak via dashboards of de datastromen correct verlopen en of de synchronisatie tussen het PIM-systeem en de verkoopkanalen aansluit bij de commerciële behoeften van de organisatie.

Als een systeem geen webhooks ondersteunt, is API polling het meest gebruikte alternatief. Hierbij vraagt jouw systeem met een vaste interval aan de bron of er nieuwe informatie beschikbaar is. Een andere optie is het gebruik van Message Queues, waarbij berichten in een wachtrij worden geplaatst totdat ze verwerkt kunnen worden. Voor minder tijdgevoelige data wordt soms nog gekozen voor batch-verwerking via SFTP, waarbij grote bestanden met productdata op vaste tijden worden uitgewisseld tussen systemen zonder dat direct actie vereist is.

Een webhook-bericht wordt verstuurd als een HTTP POST-verzoek. De inhoud, ook wel de payload genoemd, is meestal opgemaakt in JSON-formaat. Dit bericht bevat een header met metadata, zoals een beveiligingstoken om de afzender te verifiëren, en een body met de feitelijke data van de gebeurtenis. Denk aan een uniek ID, de naam van het gewijzigde product en de nieuwe waarde van een specifiek attribuut. Het ontvangende systeem leest deze JSON-structuur uit om te begrijpen welke informatie is aangepast.