Webhooks of periodieke synchronisatie: welke koppeling past bij uw proces?

Een order die pas een uur later in het voorraadsysteem opduikt. Een CRM dat iets anders laat zien dan het klantportaal. Een factuur die twee keer wordt aangemaakt. In de meeste gevallen is er niets mis met de applicaties zelf, maar met de manier waarop ze gegevens uitwisselen.

De vraag webhooks of periodieke synchronisatie wordt vaak gepresenteerd als een technische keuze. Dat is het nauwelijks. Het gaat erom hoeveel vertraging uw proces kan verdragen, wat er gebeurt als een koppeling een half uur plat ligt, en wie het merkt wanneer data niet klopt.

Zolang orders, klantgegevens en statussen netjes doorlopen, denkt niemand aan de koppeling. Dat is ook de bedoeling. Maar zodra twee systemen een andere versie van de waarheid tonen, krijgt iemand op de werkvloer er handwerk bij. En discussie.

Het praktische verschil in twee alinea's

Een webhook duwt. Zodra er iets gebeurt (een nieuwe order, een gewijzigd abonnement, een gesloten ticket) roept het bronsysteem meteen een endpoint aan dat u hebt opgegeven. Het ontvangende systeem verwerkt het bericht en daarmee is de kous af.

Periodieke synchronisatie trekt. Uw systeem vraagt elke vijf minuten, elk uur of elke nacht aan het andere systeem wat er is gewijzigd, haalt dat op en verwerkt het. Polling, in jargon.

Push tegenover pull dus, simpel gezegd. Maar die ene keuze bepaalt hoe snel processen reageren, hoeveel verkeer er over de lijn gaat, hoe u fouten opvangt en hoeveel beheer u er maandelijks in stopt.

Wanneer webhooks de juiste keuze zijn

Webhooks passen bij wijzigingen die direct gevolgen hebben. Een webshop die de beschikbaarheid in de winkelwagen moet bijwerken na een verkoop. Een toegangsplatform dat een betaling moet afhandelen voordat de bezoeker bij de deur staat. Een klantportaal dat meteen een bevestiging hoort te tonen.

De winst is snelheid: u wacht niet op de volgende ronde. Dat is vooral waardevol bij processen die de klant ziet, of waarbij een medewerker anders staat te wachten.

Daar hangt een voorwaarde aan. Het ontvangende systeem moet er zijn op het moment dat het bericht aankomt, en dat is niet altijd zo. Er loopt onderhoud, de server heeft het te druk, of de applicatie is tijdelijk niet bereikbaar. Een webhookkoppeling die u serieus neemt heeft dus verificatie van de afzender, validatie van de inhoud, logging per bericht en een leverancier die opnieuw aflevert als het de eerste keer misgaat.

Reken ook op dubbele berichten. Blijft uw ontvangstbevestiging uit, dan stuurt de leverancier hetzelfde event nog een keer. Uw verwerking moet dat opvangen: dezelfde orderupdate die twee keer binnenkomt mag geen twee facturen, twee voorraadmutaties of twee welkomstmails opleveren. Een eigen referentie per event, plus een check of u die al eerder hebt gezien, is in de praktijk meestal genoeg.

Snelheid is geen doel op zich

Kies webhooks als een paar minuten vertraging al merkbaar is, als gebruikers op een resultaat wachten, of als het gaat om weinig maar belangrijke gebeurtenissen. Betalingen, nieuwe leads, gewijzigde reserveringen, verzendingen, statusupdates.

Niet elk proces wordt beter van realtime. Wordt een status alleen intern bekeken en kan die aan het begin van de werkdag worden bijgewerkt? Dan levert directe verwerking vooral extra eisen op aan beschikbaarheid en foutafhandeling, zonder dat iemand er iets van merkt.

Wanneer periodieke synchronisatie beter werkt

Hoeven gegevens niet meteen beschikbaar te zijn, dan is een geplande synchronisatie vaak de rustigere keuze. Denk aan productinformatie, rapportages, historische data of de dagelijkse export naar de boekhouding.

Het voordeel is controle. U bepaalt wanneer de koppeling draait, hoeveel records er per keer meegaan en hoe zwaar u beide systemen belast. Dat telt wanneer een externe API harde limieten heeft, wanneer datasets groot zijn, of wanneer het bronsysteem alleen op vaste momenten betrouwbaar beschikbaar is.

Een voorbeeld: een ERP dat mutaties 's nachts in batch verwerkt. Tientallen webhooks verspreid over de dag leveren dan weinig op, want administratief gebeurt er tot die batch toch niets. Een synchronisatie die net na de nachtverwerking start sluit beter aan op de manier waarop de organisatie werkt.

Soms is er bovendien geen keuze. Veel oudere systemen en zakelijke pakketten bieden alleen een API waaruit u gegevens mag ophalen. Polling is dan geen compromis, maar simpelweg de manier waarop die software is gebouwd.

De valkuil: te vaak synchroniseren

Elke minuut synchroniseren voelt veilig. Dat is het niet automatisch. Zijn er nauwelijks wijzigingen, dan vraagt u steeds opnieuw om vrijwel dezelfde gegevens. U verbruikt API-limieten, loopt tegen kosten aan bij afrekening per verbruik, en zet uw logging vol met regels waarin niemand nog iets terugvindt.

Bepaal het interval daarom vanuit het proces en niet vanuit de techniek. Kan een klant vijf minuten op een update wachten? Dan hoeft het niet elke minuut. Wordt een leverancierscatalogus een keer per etmaal aangeleverd? Dan is een nachtelijke taak genoeg. De beste frequentie is niet de kortste, maar die bij het risico, het volume en de verwachtingen past.

In de praktijk is het vaak allebei

De keuze is zelden of/of. In koppelingen die jaren meegaan doen webhooks en periodieke synchronisatie verschillend werk: de webhook zorgt voor de snelle verwerking, de geplande synchronisatie controleert achteraf of het klopt.

Neem een orderkoppeling. De webshop stuurt een nieuwe bestelling direct door naar het fulfilmentsysteem. 's Nachts vergelijkt een synchronisatie de orders en statussen aan beide kanten. Een gemist bericht, een mislukte verwerking of een handmatige correctie komt zo binnen een dag boven water, in plaats van pas bij de maandafsluiting.

Juist bij bedrijfskritische gegevens maakt dat het verschil. De webhook geeft snelheid, de controleronde geeft herstelvermogen. Zonder die tweede laag kunnen twee systemen weken achter elkaar hun eigen werkelijkheid volgen zonder dat iemand het ziet.

Betrouwbaarheid zit in de randvoorwaarden

Webhooks, polling of een combinatie: uiteindelijk is het de omgeving eromheen die bepaalt of een koppeling overeind blijft. Een integratie zonder foutafhandeling werkt uitstekend tot het eerste netwerkprobleem, het eerste verlopen token of het eerste veld dat plotseling leeg is.

Dit zijn de onderdelen waar we in de praktijk het vaakst op terugkomen:

• Vaste identificatie van records. Beide systemen moeten weten welke klant, order of wijziging bij welk record hoort. Werk met externe ID's die niet veranderen, niet met namen of e-mailadressen.
• Logging die een mens kan lezen. Leg vast wat er binnenkwam, wat is verwerkt, wat is afgewezen en wat opnieuw is aangeboden. Alleen "error 500" op een drukke maandagochtend helpt niemand verder.
• Herstel na storing. Berichten moeten opnieuw aangeboden of opgehaald kunnen worden. Spreek ook af hoe ver u terug kunt in de tijd, want zeven dagen aan events is iets anders dan twee uur.
• Verificatie en beperkte rechten. Controleer wie een webhook verstuurt, gebruik veilige authenticatie voor API's en geef de koppeling niet meer rechten dan ze nodig heeft.
• Monitoring met een naam erbij. Een melding is pas nuttig als iemand weet dat hij van hem is. Leg vast wie reageert en binnen welke termijn.

Dat laatste punt wordt het vaakst overgeslagen. Techniek kan prima signaleren dat een synchronisatie is mislukt, maar zonder eigenaar blijft die melding een regel in een dashboard waar niemand naar kijkt.

Begin bij het proces, niet bij de API

"Ondersteunt dit pakket webhooks?" is de verkeerde eerste vraag. De betere vraag: wat gaat er operationeel mis als deze wijziging tien minuten, een uur of een dag later wordt verwerkt?

Breng per gegevensstroom in kaart wat er wordt uitgewisseld, welk systeem de bron is en wat vertraging kost. Een prijswijziging, een betaalstatus en een interne notitie hebben niet dezelfde urgentie. Leg daarbij ook vast welk systeem leidend is. Mogen CRM en ERP allebei klantgegevens aanpassen zonder regels over wie voorgaat, dan lost geen enkele synchronisatiemethode dat conflict voor u op.

Bespreek de uitzonderingen voordat er code wordt geschreven. Wat als een order wordt geannuleerd terwijl de verzending al is aangemeld? Wat als hetzelfde klantrecord in beide systemen tegelijk wordt gewijzigd? Wat als de externe API een uur niets doet? Dat soort vragen bepaalt of u een koppeling krijgt die het in een demo doet, of een koppeling waar u uw operatie op durft te laten draaien.

Houd de keuze beheerbaar

Een koppeling is niet klaar wanneer hij werkt, maar wanneer iemand anders hem over een jaar nog kan aanpassen. Documenteer dus welke systemen met elkaar praten, welke events of intervallen er zijn, waar de logs staan en hoe herstel in elkaar zit. Dat haalt de afhankelijkheid van een enkele ontwikkelaar of leverancier eruit.

Bij LJPc kijken we daarom verder dan de vraag of iets technisch kan. Ontwikkeling, hosting, monitoring en een telefoonnummer dat wordt opgenomen als er iets misgaat horen bij elkaar. Een koppeling tussen systemen moet werk weghalen, niet een nieuw aandachtspunt worden.

Kies webhooks wanneer er direct actie nodig is. Kies periodieke synchronisatie wanneer controle, voorspelbaarheid of een beperkte belasting zwaarder wegen. En gaat het om gegevens waar uw operatie op leunt, combineer dan de snelle route met een vaste controleronde. Een goede koppeling vraagt geen dagelijkse controle van uw team, maar laat zich wel binnen een dag herstellen zodra de werkelijkheid afwijkt.