Monitoring: wij zien dat het misgaat voordat je klant het merkt

Een koppeling valt zelden op de eerste dag uit

Op de dag van livegang wordt een koppeling bekeken. De storingen komen later: een API-versie die verdwijnt, een webhook die de afzender heeft uitgeschakeld, een bestand dat 's nachts niet aankomt, een veld dat de leverancier anders is gaan vullen. Een deel daarvan geeft geen foutmelding. De koppeling draait, er mislukt niets, en er komt niets meer aan.

Zonder bewaking hoort je klantenservice het van een klant. Valt de orderstroom op vrijdag om 18:00 stil en ziet iemand het maandag om 08:00, dan zijn dat 62 uur. Bij 2 orders per uur staan er dan 124 orders niet in het ERP, en moet de achterstand na het herstel ook nog worden verwerkt. Een koppeling die je zelf elke ochtend moet nakijken, heeft het werk alleen verplaatst.

Hoe een storing technisch verloopt, met wachtrij en nieuwe pogingen, staat in wat gebeurt er als een koppeling uitvalt. Deze pagina gaat over wat er gemeten wordt en wanneer er een melding komt.

Hoe werkt het?

Elke stroom heeft zijn eigen controles en zijn eigen grenzen. De controles draaien op een vast interval, gangbaar is elke 5 minuten.

De grenzen uitgerekend

Orders. Exact Online staat 60 aanroepen per minuut toe. Een order kost 3 aanroepen, dus er gaan 20 orders per minuut door. Bij 2 orders per uur wacht een order normaal minder dan een minuut. Een grens van 10 minuten is ruim boven het normale en ruim onder het moment dat een klant belt.

Afgekeurde records. De voorraadstroom over 15.000 artikelen schrijft 7.488 wijzigingen per dag. 2 per 1.000 is 7.488 gedeeld door 1.000 keer 2, afgerond 15. Bij 16 afgekeurde records op een dag gaat er een melding uit. Komen er op één ochtend 40 afgekeurd terug met dezelfde reden, dan is er waarschijnlijk iets veranderd aan de bron.

API-budget. Exact Online geeft 5.000 aanroepen per dag per administratie en meldt het restant in de header X-RateLimit-Remaining. De melding gaat uit bij 1.000 over, dus na 4.000 aanroepen of 80%. Dan is er tijd om de voorraadronde te vertragen zodat de orders door kunnen. Zie Exact Online API limieten.

Wat een melding bevat

Een melding zegt welke stroom, welke controle, de gemeten waarde, de grens en het eerste record dat het betreft:

Stroom:    orders webshop naar Exact Online
Controle:  oudste bericht in de wachtrij
Gemeten:   14 minuten (grens 10)
Wachtend:  6 orders, oudste 10482 van 09:31
Laatste fout: 401 Unauthorized op POST SalesOrders

Wat er per bericht is gebeurd, staat in de audit trail. De melding zegt dat er iets mis is, de log laat zien wat.

Wat de leveranciers veranderen

Shopify brengt elk kwartaal een nieuwe API-versie uit en ondersteunt elke versie minimaal 12 maanden. Vraagt een koppeling een versie die niet meer bestaat, dan geeft Shopify geen fout: het antwoordt met de oudste versie die er nog is. De koppeling krijgt dan antwoorden in een versie waarvoor hij niet is gebouwd. Shopify zet de gebruikte versie in de header X-Shopify-API-Version van elk antwoord, en die vergelijkt de bewaking met de versie die de koppeling vraagt. Dit staat in de documentatie van Shopify, nagelezen op 3 oktober 2026.

Webhooks vallen op een andere manier uit. Picqer verwacht binnen 10 seconden een 200, 201 of 202. Komt dat niet, dan probeert Picqer het 15 keer in ongeveer 17 uur en verwijdert daarna het bericht. Na 5 van zulke volledig mislukte berichten binnen 24 uur schakelt Picqer de webhook uit, en komt er niets meer binnen tot iemand hem opnieuw aanzet. De lijst van webhooks geeft per webhook het veld active. De bewaking leest dat bij elke controle uit. Zie de webhookdocumentatie van Picqer.

Een webhook die is uitgeschakeld, geeft de ontvanger geen enkel signaal: er komt gewoon niets meer. Daarom haalt de koppeling bij elke ronde ook via de API op wat er sinds de laatste verwerkte order is gewijzigd. Hoe webhooks werken staat in wat is een webhook.

Wat je ermee regelt

• Controles per stroom. Laatste ronde, wachtrij, afgekeurde records, budget, webhooks, API-versie en aantallen.
• Grenzen die bij je volume passen. Uitgerekend op je aantallen orders en artikelen en op de limieten van je systemen.
• Een melding met de oorzaak. Stroom, controle, gemeten waarde en het eerste record.
• Aanpassen voordat iets verdwijnt. Changelogs en aankondigingen van je leveranciers gevolgd, de koppeling bijgewerkt voor de oude versie stopt.
• Herstel zonder overtypen. Wat in de wachtrij of op de foutenlijst staat, wordt na herstel verwerkt. Zie orders, klanten en verzending.

Welke stromen er zijn en hoe ze samenhangen staat op koppelingen. Wat er bij livegang vooraf wordt gecontroleerd staat bij dry run en goedkeuring.

Wat een standaardkoppeling hier niet doet

Bij standaardkoppelingen en koppelplatformen gaat een foutmelding naar de gebruiker: een e-mail of een regel in een overzicht als een aanroep mislukt. Wat er gebeurt als er niets mislukt en er toch niets aankomt, komt in hun documentatie niet voor. Een uitgeschakelde webhook, een API-versie die stil is vervangen of een bestand dat niet is aangekomen, geeft in die opzet geen melding.

Voor de orderstroom uit het voorbeeld betekent dat: Picqer schakelt de webhook op vrijdagavond uit, er mislukt daarna geen enkele aanroep meer, en de eerste die het merkt is een klant die naar zijn order vraagt.

Wij bouwen de koppeling op jouw systemen en draaien en bewaken hem daarna: de controles, de grenzen en de meldingen horen bij het beheer. In het dashboard zie je per stroom de stand. Vertel welke systemen je koppelt.