Een webhookstorm vang je veilig op door snelle meldingen over dezelfde order kort te bundelen, daarna de nieuwste ordergegevens op te halen en elke ontvangen melding wel in het auditspoor te bewaren. Alleen een wachtrij is niet genoeg: zonder bundeling kan één checkout vijf bijna gelijke synchronisaties starten en daardoor onnodige API-belasting, verouderde updates en dubbele vervolgacties veroorzaken.
Waarom één bestelling meerdere meldingen geeft
WooCommerce kan rond één bestelling achtereenvolgens een creatie, betaalstatus, voorraadmutatie en orderupdate melden. Plug-ins voor betalingen, fulfilment of maatwerkvelden kunnen daar extra updates aan toevoegen. Dat is normaal gedrag; het wordt pas een probleem wanneer ieder bericht zelfstandig een volledige keten naar ERP, vervoerder en klantenservice start.
Een robuuste integratielaag maakt daarom onderscheid tussen ontvangst en verwerking. Ontvangst moet snel, duurzaam en traceerbaar zijn. Verwerking mag enkele seconden wachten om te zien of er nog een nieuwere melding voor hetzelfde ordernummer volgt. De bundelaar kiest vervolgens één kandidaat, maar verwijdert de andere gebeurtenissen niet uit de historie. Zo blijft later zichtbaar waarom verwerking op dat moment begon.
De burstbeslisboom
- Gaat het om dezelfde winkel én hetzelfde orderobject? Alleen dan mogen meldingen samen. Gelijke ordernummers uit verschillende webshops zijn verschillende orders.
- Valt de melding binnen het korte bundelvenster? Wacht lang genoeg om een checkout-burst op te vangen, maar niet zo lang dat fulfilment merkbaar wordt vertraagd.
- Is een eerdere verwerking al gestart? Markeer de nieuwe gebeurtenis voor een vervolgcontrole in plaats van twee processen tegelijk dezelfde order te laten schrijven.
- Welke versie is het nieuwst? Gebruik niet blind het laatst ontvangen bericht; haal waar mogelijk de actuele order op en vergelijk wijzigingstijden.
- Welke vervolgstappen zijn al gelukt? Herhaal een verzendlabel of betaling nooit alleen omdat de bron opnieuw meldde.
Deze aanpak past bij een betrouwbare koppeling tussen webshop en ERP: gebeurtenissen zijn signalen om gecontroleerd werk te starten, niet automatisch de waarheid waarmee alle systemen worden overschreven.
Fictief voorbeeld: drie updates in twaalf seconden
Stel dat webwinkel Noord & Noot order 4812 ontvangt. Om 10:03:01 meldt WooCommerce dat de order is aangemaakt. Vier seconden later bevestigt de betaalplug-in de betaling. Op 10:03:12 vult een verzendplug-in een afleverinstructie aan. Zonder bundeling kunnen drie AFAS-verkooporders en drie pakketopdrachten worden geprobeerd.
Met bundeling worden alle drie meldingen geregistreerd onder dezelfde winkel en order. Na het venster haalt Connect de actuele order opnieuw op. Die bevat de betaalstatus én afleverinstructie. Eén primaire verwerking maakt de financiële order aan. Pas na dat succes wordt de passende logistieke stap vrijgegeven. In Desk blijft de tijdlijn tonen dat drie bronmeldingen tot één verwerkingsronde zijn samengevoegd. Dit voorbeeld is fictief; het laat zien welk probleem de technische volgorde oplost.
Wat je tijdens implementatie moet meten
| Signaal | Gezonde uitkomst | Onderzoek bij afwijking |
|---|---|---|
| Meldingen per order | Alle meldingen blijven vindbaar | Ontbrekende webhookregistratie |
| Verwerkingen per burst | Meestal één primaire run | Te kort venster of verkeerde sleutel |
| Nieuwste wijziging | Actuele bronversie verwerkt | Klok, cache of late aflevering |
| Vervolgacties | Geen dubbele labels of boekingen | Ontbrekende idempotentie of ontvangstcontrole |
Kijk niet alleen naar snelheid. Belangrijker zijn het aantal samengevoegde gebeurtenissen, de leeftijd van de gekozen bronversie en het aantal acties dat na een onzekere fout handmatig aandacht nodig heeft. In Yindle Connect kan zo’n stroom als configureerbare workflow worden ingericht; in Yindle Desk kan een medewerker de uitzonderingen en het auditspoor beoordelen.
Test het bundelvenster bovendien met verkeer dat op jouw winkel lijkt. Maak een proefreeks met één gewone checkout, een betaalbevestiging die twintig seconden later komt, twee identieke updates en een correctie terwijl de eerste verwerking al loopt. Controleer niet alleen hoeveel jobs starten, maar ook welke ordertoestand uiteindelijk in ieder doelsysteem staat. Een agressief venster kan de eerste verwerking netjes reduceren en toch een latere, inhoudelijk relevante wijziging missen. Daarom hoort na een lopende verwerking een gerichte vervolgcontrole te bestaan. Leg als acceptatiecriterium vast dat de laatste geldige bronwijziging aantoonbaar is verwerkt en dat niet-herhaalbare neveneffecten hoogstens één keer zijn uitgevoerd.
Wil je weten waar jouw webshop onnodig vaak dezelfde order verwerkt? Laat één representatieve webhookreeks met ons doorlichten.