Kennisbank
Wat gebeurt er als een koppeling uitvalt?
Je webshop blijft verkopen, want afrekenen hangt in de meeste webshops niet van het ERP af. Wat stilstaat is het verkeer tussen de systemen. Of je daarna orders mist, hangt af van één ding: bewaart de koppeling wat hij niet kan afleveren en biedt hij het opnieuw aan, of is een mislukt bericht weg.
Bijgewerkt op
Kan je webshop blijven verkopen?
In de meeste gevallen wel. Een webshop slaat een order op in zijn eigen database en heeft het ERP niet nodig om het afrekenen af te ronden. Valt de koppeling of het ERP uit, dan stopt het verkeer tussen de systemen, en elke stroom loopt op zijn eigen manier achter.
| Stroom | Tijdens de storing | Wat het kost |
|---|---|---|
| Orders naar het ERP | Orders blijven in de webshop staan | Het magazijn ziet ze niet. Bij 24 orders per uur zijn dat na 2 uur en 15 minuten 54 orders die later gepickt worden |
| Voorraad naar de webshop | De webshop toont de laatst ontvangen stand | 32 getoond, 7 verkocht in de winkel: de webshop biedt 7 stuks te veel aan |
| Prijzen naar de webshop | De oude prijs blijft staan | Orders tegen de prijs van gisteren |
| Verzendstatus naar de webshop | Geen trackcode, geen verzendmail | Klanten bellen waar hun pakket is |
Orders mogen nooit verloren gaan; te laat is te herstellen. Bij voorraad doet de vertraging zelf de schade, want op een stand van twee uur oud is al verkocht. Welke voorraad de webshop hoort te tonen staat in welke voorraad toon je in je webshop.
De uitzondering is een webshop die bij het afrekenen live iets opvraagt. Dan staat bij een storing ook de verkoop stil, tenzij er een vangnet is ontworpen. Deze vraag hoort bij het ontwerp en wordt daar vaak overgeslagen.
| De webshop vraagt live op | Zonder vangnet | Vangnet |
|---|---|---|
| Klantspecifieke prijs | Geen prijs, of de standaardprijs | De prijslijst vooraf naar de webshop synchroniseren en die tonen |
| Kredietlimiet bij bestellen op rekening | Bestellen op rekening werkt niet | Order aannemen met de status wacht op controle |
| Voorraad op het moment van bestellen | Het afrekenen wacht tot de time-out | Na 2 seconden terugvallen op de laatst bekende stand |
Wat er met de berichten gebeurt
Bij een koppeling met een wachtrij wordt een bericht opgeslagen voordat het wordt verstuurd, en pas verwijderd als het ontvangende systeem het heeft bevestigd. Een mislukte poging laat het bericht staan. Wat er daarna gebeurt, hangt af van het soort fout.
| Antwoord | Betekenis | Wat de koppeling doet |
|---|---|---|
Time-out, 502, 503 |
Het systeem is onbereikbaar | De stroom pauzeren en opnieuw proberen met oplopende pauzes |
429 |
De limiet is bereikt | Wachten tot de limiet weer ruimte geeft |
400, 422 |
Dit ene record wordt geweigerd | Niet opnieuw proberen. Naar de lijst met mislukte berichten; de rest van de wachtrij gaat door |
401 |
De aanmelding is verlopen | De stroom stoppen en direct melden |
Nieuwe pogingen met oplopende pauzes
Een voorbeeld. Op maandagochtend geeft de API van het ERP van 09:30 tot 11:45 een 503. De koppeling probeert het na 1 minuut opnieuw, dan na 2, 4, 8 en 16 minuten, en daarna elke 30 minuten. Dat zijn pogingen om 09:31, 09:33, 09:37, 09:45, 10:01, 10:31, 11:01 en 11:31. De poging van 12:01 lukt.
In 2 uur en 31 minuten zijn dat 9 mislukte aanroepen. Een koppeling die elke 5 seconden opnieuw probeert, doet er in de 135 minuten van de storing 1.620, tegen een systeem dat al problemen heeft. De pauzes lopen op om het ontvangende systeem ruimte te geven, en ze zijn begrensd op 30 minuten zodat het herstel niet onnodig lang onopgemerkt blijft: hier 16 minuten.
Tussen 09:30 en 12:01 zijn 60 orders binnengekomen, bij 24 per uur. Ze gaan er op volgorde in. Elke order kost 4 aanroepen (klant zoeken, order aanmaken, regels, bevestiging): 240 aanroepen. Bij een limiet van 60 per minuut, zoals Exact Online die hanteert, is de wachtrij om 12:05 leeg. Waarom die limiet de snelheid bepaalt staat in rate limits en throttling.
De lijst met mislukte berichten
Een bericht dat om een inhoudelijke reden wordt geweigerd, komt bij elke poging met dezelfde fout terug. Na een beperkt aantal pogingen gaat het naar een aparte lijst, in het Engels de dead letter queue. Het bericht staat er compleet:
{
"stroom": "orders-naar-erp",
"pogingen": 3,
"eerste_poging": "2026-10-05T12:03:10+02:00",
"laatste_fout": "400 Artikel KB-2215 is geblokkeerd",
"bericht": {
"order": "10497",
"klant": "Bakker Installatie B.V.",
"regels": [ { "sku": "KB-2215", "aantal": 6, "prijs": "17.08" } ]
}
}
De andere 59 orders gaan door; deze ene wacht tot iemand artikel KB-2215 in het ERP heeft vrijgegeven. Daarna wordt het bericht opnieuw aangeboden en verwerkt als een nieuwe order. Er hoeft niets uit de webshop te worden overgetypt.
Eén order per order
Een nieuwe poging na een time-out is de bekendste bron van een dubbele verkooporder. Het ERP heeft de order aangemaakt, het antwoord kwam niet aan, en de koppeling stuurt hem nog een keer. De koppeling zet daarom het ordernummer van de webshop in het referentieveld en zoekt daar eerst op. Meer hierover in dubbele klanten en debiteuren.
Ook de afzender geeft het op
De storing kan ook aan de kant van de koppeling zitten. Dan bepaalt de afzender hoe lang een bericht blijft bestaan. Shopify wacht 5 seconden op een antwoord op een webhook, probeert het 8 keer opnieuw in 4 uur en verwijdert daarna het abonnement als het via de Admin API is aangemaakt. Dat staat in de documentatie van Shopify. Staat de ontvanger langer dan 4 uur stil, dan zijn de berichten van die uren weg en komen er geen nieuwe. Een controleronde die via de API opvraagt wat er sinds de laatste verwerkte order is binnengekomen, haalt ze terug. Zie wat is een webhook.
Hoe je het merkt
Een volledige storing is het makkelijke geval: elke aanroep mislukt en de wachtrij groeit. Een gangbare opzet is een controle elke 5 minuten op twee dingen: het tijdstip van de laatste gelukte ronde en het aantal wachtende berichten. In het voorbeeld gaat de melding om 09:35 uit, 5 minuten na de eerste mislukte order en ruim voordat een klant belt.
Zonder bewaking wordt een kapotte koppeling ontdekt door een klant. Dan is er de fout en ook de achterstand om weg te werken.
De storingen die meer kosten zijn de storingen zonder foutmelding. Er mislukt geen enkele aanroep en toch komt er niets meer aan.
| Storing zonder foutmelding | Wat je ziet | Hoe het wordt gevonden |
|---|---|---|
| Het bestand van de leverancier is vannacht niet aangekomen | De voorraad van gisteren blijft staan | Controle op het tijdstip van het laatste bestand |
| Shopify heeft het webhook-abonnement verwijderd na 8 mislukte afleveringen | Er komen geen orders meer binnen | Elke ronde controleren of het abonnement nog bestaat |
| Het nieuwe refresh token van Exact Online is niet opgeslagen | Elke aanroep geeft 401 tot iemand opnieuw inlogt |
Token opslaan voordat het wordt gebruikt; melding bij de eerste 401 |
| De daglimiet is bereikt | De stroom staat stil tot de volgende dag | Het resterende budget per aanroep uitlezen en melden voordat het op is |
| Eén record valt af op een regel in de koppeling | Eén order of artikel ontbreekt | Dagelijkse vergelijking van aantallen aan beide kanten |
Bij Exact Online is een refresh token geldig tot het volgende token is opgevraagd. Gaat het nieuwe token verloren tussen ontvangen en opslaan, dan is het oude al ongeldig en staat de koppeling stil tot een gebruiker opnieuw toestemming geeft. Een bestand dat niet aankomt is het onderwerp van koppelen zonder API.
Wat standaardkoppelingen en koppelplatformen doen
Wat er bij een storing gebeurt, is per product anders en staat zelden op de verkooppagina. Drie gedragingen die in de documentatie van zulke producten en van de systemen zelf beschreven staan:
Pauzeren tot de volgende dag. Exact Online staat per app en per administratie 5.000 aanroepen per dag toe. Daarna krijgt elke aanroep een 429 tot het budget de volgende dag opnieuw begint. Een koppeling die om 15:10 door zijn budget heen is, staat stil tot 00:00: 8 uur en 50 minuten. Bij 24 orders per uur wachten er dan 212 orders. Hoe je dat budget verdeelt staat in Exact Online API limieten.
Uitschakelen tot iemand kijkt. Er zijn koppelplatformen die een stroom bij een aanmeldfout na 5 tot 10 minuten herstarten, het na een uur nog één keer proberen en de stroom daarna uitschakelen tot een gebruiker hem weer aanzet. Valt dat op vrijdag om 18:00, dan staat de stroom tot maandagochtend 08:00 stil: 62 uur.
Geen wachtrij. Een plugin of feed die rechtstreeks van systeem naar systeem stuurt, heeft geen plek om een mislukt bericht te bewaren. De volgende ronde stuurt de nieuwe stand; wat in de mislukte ronde zat, is alleen terug te vinden door beide systemen te vergelijken.
Vijf vragen die het gedrag van elke koppeling vastleggen, met de antwoorden uit het voorbeeld:
| Vraag | Antwoord in het voorbeeld |
|---|---|
| Waar wacht een bericht dat niet afgeleverd kan worden? | In een wachtrij, tot het ERP het bevestigt |
| Hoe vaak en hoe lang wordt het opnieuw geprobeerd? | Na 1, 2, 4, 8 en 16 minuten, daarna elke 30 minuten |
| Waar komt een bericht dat geweigerd blijft? | Op een lijst, met de inhoud en de foutmelding |
| Wie krijgt een melding, en na hoeveel minuten? | De beheerder, na 5 minuten |
| Wat gebeurt er bij de daglimiet? | Melding voordat het budget op is; orders gaan voor op voorraad |
Wat betekent dit voor je koppeling?
Wij bouwen een koppeling met een wachtrij, nieuwe pogingen met oplopende pauzes, een controle op dubbele orders en een lijst met mislukte berichten, zodat er niets stil verdwijnt. Daarna draaien en bewaken wij hem: een mislukte ronde levert bij ons een melding op, en verandert de bron, bijvoorbeeld een API of een bestand, dan passen wij de koppeling aan. In het dashboard zie je per bericht de pogingen en de eindstand, en zoek je op wat er met één order is gebeurd.
Hoe bewaking en meldingen zijn opgezet staat op monitoring van je koppeling. De orderstroom met zijn velden staat op orders, klanten en verzending. Vertel welke systemen je gebruikt en wat er de laatste keer misging.
Veelgestelde vragen
Kan mijn webshop blijven verkopen als de koppeling of het ERP uitvalt?
Ja, zolang het afrekenen niets live bij het ERP opvraagt. De webshop slaat de order zelf op. Vraagt de webshop bij het afrekenen wel iets op, zoals een klantspecifieke prijs of een kredietlimiet, dan is een vangnet nodig: de laatst bekende prijs gebruiken, of de order aannemen met de status wacht op controle.
Raak ik orders kwijt als het ERP offline is?
Niet bij een koppeling met een wachtrij. Elke order wordt opgeslagen voordat hij wordt verstuurd en blijft staan tot het ERP hem bevestigt. Na de storing gaan de orders er op volgorde alsnog in. Een order die om een inhoudelijke reden wordt geweigerd, komt met de reden op een aparte lijst en kan na herstel opnieuw worden aangeboden.
Krijg ik dubbele orders als de koppeling het opnieuw probeert?
Dat gebeurt als de koppeling opnieuw verstuurt zonder te controleren. De gebruikelijke oorzaak is een time-out: het ERP heeft de order aangemaakt en de bevestiging kwam niet aan. De koppeling stuurt daarom het ordernummer van de webshop mee als referentie en zoekt daar eerst op. De tweede poging vindt de eerste order en maakt niets aan.
Hoe merk ik dat een koppeling stilstaat?
Via bewaking die op vaste momenten twee dingen controleert: wanneer de laatste ronde is gelukt en of de wachtrij groeit. Is een van beide niet in orde, dan gaat er een melding uit met de stroom en de foutmelding. Zonder bewaking merk je het via een klant die naar zijn order vraagt, uren of dagen later.
Wat is een dead letter queue?
De lijst waar een bericht terechtkomt als het na de laatste poging nog steeds wordt geweigerd. Het bericht staat er met de oorspronkelijke inhoud, de laatste foutmelding en het aantal pogingen. Er wordt niets weggegooid. Is de oorzaak verholpen, bijvoorbeeld een geblokkeerd artikel dat weer actief is, dan wordt het bericht opnieuw aangeboden.
Hoe lang duurt het voordat de achterstand na een storing is weggewerkt?
Dat is een rekensom: het aantal wachtende berichten maal de aanroepen per bericht, gedeeld door de limiet van het ontvangende systeem. 60 orders van elk 4 aanroepen zijn 240 aanroepen. Bij een limiet van 60 per minuut is de achterstand in 4 minuten weg, als er in die minuten niets anders loopt.
Vertel wat je nodig hebt
Vertel welke systemen je gebruikt en wat je wilt verbeteren. Je krijgt binnen één werkdag een persoonlijk antwoord. We helpen je de werkzaamheden helder te krijgen en spreken de prijs en planning af voordat je iets toezegt.
- Je weet de prijs en de doorlooptijd voordat je iets toezegt
- Wij zoeken uit welke koppeling het werk uit handen neemt
- Wij verzorgen de bouw, hosting, bewaking en het onderhoud
- Je team krijgt minder overtypwerk en minder uitzoekwerk