Downtime voorkomen bij systeemkoppelingen: zo bouw je betrouwbare integraties

Door Clen Mourik

Een koppeling die 's nachts uitvalt en pas de volgende ochtend ontdekt wordt. Orders die verdwijnen. Voorraad die niet klopt. Herkenbaar? Zo zorg je dat je systeemintegraties blijven werken, ook als er iets misgaat.

Vorige week kreeg ik een telefoontje van een productiebedrijf. Paniek in de stem. Hun koppeling tussen webshop en productiesysteem was vrijdagmiddag uitgevallen. Niemand had het gemerkt. Maandag kwamen ze erachter: 15 orders niet doorgekomen, productieplanning compleet in de war, klanten die belden waar hun spullen bleven.

Het vervelende? Dit was volledig te voorkomen geweest. Een simpele monitor die checkt of er orders binnenkomen had het binnen 20 minuten gesignaleerd. In plaats daarvan: een weekend lang stilstand en maandag acute brandjes blussen.

Even eerlijk: de meeste systeemkoppelingen in het MKB zijn gebouwd met de aanname dat alles altijd werkt. Tot het niet meer werkt. En dan is het leed niet te overzien.

Inhoudsopgave

• Belangrijkste punten
• Wat downtime je écht kost
• Waarom koppelingen uitvallen
• De 5 meest gemaakte fouten
• Hoe bouw je een betrouwbare architectuur
• Praktijkvoorbeeld: WooCommerce naar Picqer
• Monitoring en alerting die werkt
• Onderhoud en updates
• Veelgestelde vragen

Belangrijkste punten

Wat downtime je écht kost

Laten we daar beginnen. Want de meeste bedrijven onderschatten dit gigantisch.

Het CBS becijfert dat de gemiddelde kosten van IT-downtime voor Nederlandse MKB-bedrijven tussen de €6.000 en €10.000 per uur liggen. En dat is gemiddeld. Voor bedrijven met e-commerce of productieprocessen kan dit tijdens piekperiodes oplopen tot €25.000 per uur.

Maar het gaat niet alleen om directe kosten. Denk aan:

• Medewerkers die stilzitten omdat hun systeem niet werkt
• Orders die je mist omdat klanten niet kunnen bestellen
• Voorraadfouten waardoor je dingen verkoopt die je niet hebt
• Goodwill-kortingen en coulance omdat je leverbeloftes niet nakomt
• Slechte reviews omdat klanten hun spullen te laat krijgen
• Uren werk om handmatig data te fixen achteraf

Bij een meubelzaak die ik ken kostte een eenvoudig voorraadprobleem meer dan je denkt. Ze hadden 80 online orders per dag, maar hun voorraad werd handmatig in Excel bijgehouden. Magazijnmedewerkers werkten overdag met die Excel, 's avonds kwamen webshop-orders binnen. Het gevolg: 3 tot 4 keer per week moest customer service bellen dat een product toch niet leverbaar was. Hun score op reviews daalde van 4,2 naar 3,6 sterren. Dat kost je klanten.

Wat veel ondernemers niet doorhebben: één storing per maand lijkt niet veel, maar als die storing telkens 6-8 uur werk kost om op te lossen, ben je 3-4 werkdagen per jaar kwijt aan brandjes blussen.

Waarom koppelingen uitvallen (en waarom je het te laat merkt)

In de praktijk zie ik steeds dezelfde oorzaken terugkomen:

API-keys die verlopen. Veel systemen roteren automatisch hun API-credentials na 90 dagen. Als je dat niet in je agenda hebt staan, staat je koppeling opeens stil. Bij dat productiebedrijf dat ik noemde was dit precies het probleem. De API-key was verlopen, maar niemand had dat in de gaten omdat er geen monitoring was.

Softwareupdates met breaking changes. Stel: Exact Online voegt een verplicht veld toe aan hun API. Jouw koppeling stuurt dat veld niet mee. Vanaf het moment van die update krijg je errors. Als je daar niet op let, loop je tegen problemen aan.

Rate limiting. Je webshop doet opeens een Black Friday-actie. Normaal 50 orders per dag, nu 500. Je koppeling stuurt voor elke order 3 API-calls naar je boekhouding. Dat zijn er ineens 1500 op één dag. Het systeem aan de andere kant zegt: te veel requests, even dimmen. Orders komen niet meer door.

Timeout-problemen. Je ERP-systeem is even traag omdat er een backup draait. Normaal reageert de API binnen 2 seconden, nu duurt het 45 seconden. Je koppeling heeft een timeout van 30 seconden. Result: alles loopt vast.

Netwerkstoringen. Kan gebeuren. Server herstart, DNS-probleem, je hostingpartij heeft een storing. Als je koppeling daar niet mee om kan gaan, betekent 5 minuten netwerkprobleem dat je 2 uur aan gemiste orders hebt.

Waar het op neerkomt: je bouwt een koppeling niet voor als alles perfect loopt. Je bouwt hem voor als het misgaat. En het gaat altijd weleens mis.

De 5 meest gemaakte fouten bij systeemintegraties

Fout 1: Geen error handling en retry-logica

Dit is de nummer één fout die ik tegenkom. De koppeling werkt prima tijdens het testen. Alles happy flow. Maar zodra er iets misgaat — timeout, API tijdelijk down, verkeerd dataformaat — crasht de hele boel.

Wat je nodig hebt: exponential backoff retry. Probeer het opnieuw na 1 minuut. Lukt het niet? Probeer na 5 minuten. Dan 15 minuten. Dan een uur. En log alles wat misgaat in een queue zodat je het later kunt afhandelen.

Fout 2: Synchrone koppelingen zonder fallback

Stel: een klant wil iets bestellen in je webshop. Je checkout moet eerst even checken bij het ERP-systeem of het product op voorraad is. Dat ERP-systeem heeft net een backup draaien en reageert traag. Na 30 seconden krijgt de klant een timeout. Bestelling weg. Klant gefrustreerd.

Betere aanpak: werk asynchroon waar het kan. Of gebruik cached voorraaddata die elke 5 minuten ververst wordt. Dan kan de checkout gewoon doorgaan, ook als het ERP even traag is.

Fout 3: Geen monitoring en alerting

De koppeling werkt. Niemand kijkt er nog naar. Tot het niet meer werkt.

Bij een groothandel die ik ken liep elke nacht een batch-sync tussen hun ERP en hun verkoopkanalen. Als die batch faalde — server herstart, API timeout, whatever — merkten ze dat pas de volgende ochtend. Dan hadden ze al 20-30 orders aangenomen terwijl de voorraad niet klopte.

Dit gebeurde gemiddeld één keer per maand. Elke keer kostte het 6-8 uur werk van twee medewerkers om handmatig te checken welke orders wel of niet geleverd konden worden. Plus goodwill-kortingen voor klanten.

Wat er ontbrak: een simpele check die om de 15 minuten kijkt of de koppeling nog data uitwisselt. Als dat niet zo is: alert via WhatsApp. Probleem opgelost binnen 20 minuten in plaats van 8 uur later.

Fout 4: Single point of failure

Alles loopt via één server, één API-key, één netwerkverbinding. Als die uitvalt, ligt alles plat.

Ik ben geen voorstander van overengineering voor het MKB, maar een beetje redundantie op kritieke plekken scheelt veel hoofdpijn. Bijvoorbeeld: houd essentiële voorraaddata lokaal in een cache. Als de API van je leverancier even niet bereikbaar is, kun je toch gewoon doorwerken met data van 10 minuten geleden.

Fout 5: Updates worden direct in productie doorgevoerd

Je hebt een slimme developer die de koppeling wil verbeteren. Die past wat aan. Zet het direct live. Blijkt dat er ergens een foutje in zit. Oeps. Nu zitten je live klanten ermee.

Essentieel: een testomgeving. Kopieer je productiedata, test daar eerst. Werkt het? Dan pas live zetten.

Hoe bouw je een betrouwbare architectuur

Nu de praktijk. Hoe doe je het wél goed?

Kies de juiste methode voor jouw situatie

Er zijn grofweg vier manieren om systemen te koppelen. Elk heeft voor- en nadelen:

Voor de meeste MKB-bedrijven werkt een combinatie het beste. Kritieke data real-time via webhooks, minder tijdgevoelige zaken via een queue die op de achtergrond draait.

Bouw in wat fout kan gaan

Hier zijn de dingen die je altijd moet afvangen:

• API die tijdelijk niet bereikbaar is: retry met backoff
• Timeout na 30 seconden: verhoog de timeout of maak de call asynchroon
• Invalid data (verkeerde postcode, leeg veld): valideer vooraf en log de error
• Rate limiting: bouw throttling in zodat je niet te veel requests tegelijk doet
• Dubbele berichten: check of deze order/factuur/klant al eerder verwerkt is

Ik zeg altijd: als je koppeling alleen werkt als alles perfect loopt, dan werkt hij niet. Bouw voor de 5% scenario's waarin het misgaat, dan heb je 95% minder problemen.

Praktijkvoorbeeld: WooCommerce naar Picqer

Laten we concreet worden. Een klassiek voorbeeld: een webshop op WooCommerce die groeit en een magazijnsysteem nodig heeft. Picqer is daar populair voor. Hoe zorg je dat die koppeling betrouwbaar is?

De flow die je wilt

Zo moet het werken:

1. Klant plaatst order in je WooCommerce webshop
2. WooCommerce stuurt direct een webhook naar je middleware
3. Middleware mapt de order naar het Picqer-formaat (klantgegevens, producten, verzendmethode)
4. API-call naar Picqer: order wordt aangemaakt
5. Picqer creëert automatisch een picklijst
6. Magazijnmedewerker scant de producten met de Picqer-app
7. Bij afronding: voorraad wordt automatisch bijgewerkt
8. Picqer stuurt track & trace terug naar WooCommerce
9. WooCommerce mailt de klant dat het pakket onderweg is

In een ideale wereld gebeurt dit binnen 30 seconden nadat de klant op "Bestellen" klikt.

Wat er mis kan gaan

En nu de realiteit. Dit zijn de scenario's waar je rekening mee moet houden:

Product bestaat in WooCommerce maar niet in Picqer. Nieuwe producten worden toegevoegd aan de webshop, maar iemand vergeet ze in Picqer aan te maken. Order komt binnen, koppeling faalt. Oplossing: check vooraf of het product bestaat, zo niet: stuur een alert en zet de order in een wachtrij voor handmatige afhandeling.

Voorraad is 0 maar order is al geplaatst. Race condition. Twee mensen bestellen hetzelfde artikel tegelijk. Eén komt door, de ander niet. Oplossing: real-time voorraadsync (elke 30 seconden) en een check bij checkout of het product nog beschikbaar is.

Picqer API is tijdelijk offline voor maintenance. Gebeurt soms. Oplossing: queue-systeem. Orders blijven lokaal in een wachtrij staan, worden automatisch verstuurd zodra Picqer weer online is.

Invalid data. Klant vult een postcode in met spaties of rare tekens. Picqer accepteert dat niet. Oplossing: valideer en clean de data voordat je hem naar Picqer stuurt.

Technische keuzes die het verschil maken

Webhooks of polling? Voor WooCommerce-Picqer raad ik webhooks aan. Direct, real-time, geen onnodige API-calls. Maar zorg wel dat je duplicaten afvangt — soms stuurt WooCommerce een webhook twee keer.

Rate limiting: Picqer heeft een limiet van ongeveer 300 requests per minuut. Als je ineens 50 orders tegelijk binnenkrijgt (Black Friday), moet je throttling inbouwen zodat je niet over die limiet heen gaat.

Idempotency: als dezelfde order per ongeluk twee keer verstuurd wordt, moet Picqer dit herkennen via het unieke order-ID en niet dubbel verwerken.

Meer details over deze WooCommerce integratie vind je op onze integratiepagina.

Monitoring en alerting die werkt

Oké, je hebt een mooie koppeling gebouwd. Nu moet je zorgen dat je weet wanneer het misgaat.

Drie lagen van monitoring

Laag 1: Is de API bereikbaar? Tools zoals UptimeRobot of Pingdom checken elke 5 minuten of de API endpoint een 200 OK teruggeeft. Zo niet: alert.

Laag 2: Komt er daadwerkelijk data door? Dit is belangrijker. Stel: je verwacht normaal 10-20 orders per dag. Als er in 8 uur tijd 0 orders zijn binnengekomen, is er waarschijnlijk iets mis. Ook al is de API bereikbaar. Bouw een check die dit detecteert.

Laag 3: Zijn er errors in de logs? Gebruik tools zoals Sentry of Rollbar om errors te loggen. Als dezelfde error 10 keer in een uur voorkomt, stuur een alert. Niet voor elke individuele fout, want dan krijg je alert-moeheid.

Alerts die mensen daadwerkelijk lezen

Ik zie vaak dat bedrijven wel monitoring hebben, maar de alerts gaan naar een e-mailadres dat niemand checkt. Of naar een Slack-kanaal dat iedereen op mute heeft gezet.

Wat werkt:

• WhatsApp-bericht naar 2-3 mensen die ervoor verantwoordelijk zijn
• SMS voor kritieke systemen (je leest een SMS altijd, ook 's avonds)
• Escalatie: als de eerste persoon niet binnen 15 minuten reageert, gaat de alert naar de volgende

En belangrijk: test je alerts. Echt. Eén keer per kwartaal een test-alert sturen om te checken of het systeem werkt.

Onderhoud en updates: de vergeten factor

Je koppeling is live. Prima. Maar over 6 maanden komt Exact Online met een API-update. Of WooCommerce past hun webhook-structuur aan. Als je daar niet op let, staat je koppeling opeens stil.

Wat je nodig hebt:

• Documentatie van welke API-versies je gebruikt
• Een testomgeving waar je updates eerst kunt testen
• Een changelog bijhouden van wat je wanneer hebt aangepast
• Alerts volgen van je softwareleveranciers (meestal via hun developer-nieuwsbrieven)

Voor veel MKB-bedrijven is dit te veel gevraagd om zelf bij te houden. Daarom besteden ze dit uit. Bij SyncIT monitoren we bijvoorbeeld alle API's waar we mee werken en informeren we klanten proactief als er iets gaat veranderen.

Een overzicht van alle 176+ systemen waarmee we integreren vind je op onze website.

API-credentials die verlopen

Dit blijft een issues. Veel systemen roteren hun keys automatisch. Oplossing: zet het in je agenda. Of nog beter: gebruik tokens die automatisch vernieuwen (refresh tokens) waar mogelijk.

Breaking changes vs backwards compatible updates

Niet elke API-update breekt je koppeling. Meestal zijn updates backwards compatible — nieuwe functionaliteit wordt toegevoegd, maar oude calls blijven werken.

Maar soms niet. Bijvoorbeeld als een verplicht veld wordt toegevoegd. Of een datatype verandert. Daarom is het belangrijk dat je API-wijzigingen bijhoudt en test voordat ze live gaan.

Veelgestelde vragen

Hoeveel kost het om een betrouwbare systeemkoppeling te bouwen?

Dat hangt af van de complexiteit. Een simpele koppeling tussen twee systemen via een platform als Make of Zapier kost €50-300 per maand aan software, plus enkele uren setup. Voor maatwerk met volledige error handling, monitoring en retry-logica rekenen we bij SyncIT €2.500-6.000 afhankelijk van het aantal systemen en de specifieke eisen. Daar zit dan alles in: ontwikkeling, testing, documentatie en de eerste maanden support.

Kan ik niet gewoon een standaard plugin gebruiken?

Voor veel standaard use cases wel. WooCommerce heeft bijvoorbeeld plugins voor koppelingen met populaire systemen. Die werken prima voor de basis. Maar zodra je specifieke wensen hebt — bijvoorbeeld custom productvelden, complexe voorraadlogica, of koppelingen met meerdere systemen tegelijk — loop je snel tegen de beperkingen aan. Dan is maatwerk nodig.

Wat is het verschil tussen real-time en batch-synchronisatie?

Real-time betekent dat data direct wordt uitgewisseld zodra er iets gebeurt. Order komt binnen, wordt meteen doorgestuurd. Batch-synchronisatie verzamelt data en verstuurt het in één keer, bijvoorbeeld elk uur of elke nacht. Real-time is beter voor tijdkritieke processen zoals voorraad of orders. Batch is vaak voldoende voor bijvoorbeeld klantgegevens of productinformatie.

Hoe voorkom ik dat mijn koppeling uitvalt tijdens Black Friday?

Belangrijkste: load testing vooraf. Simuleer 5x je normale volume en kijk of alles blijft werken. Zorg voor throttling zodat je niet tegen API-limieten aanloopt. En heb een fallback-scenario: als de koppeling het niet redt, kunnen orders lokaal worden opgeslagen en later verwerkt? Kritiek is ook: goede monitoring zodat je direct ziet als er iets mis gaat.

Wat moet ik doen als mijn huidige koppeling regelmatig problemen geeft?

Start met diagnose. Log alle errors en kijk waar het patroon zit. Valt het altijd op hetzelfde tijdstip uit? Bij een bepaald type order? Dan weet je waar je moet zoeken. Vaak zijn de problemen op te lossen met betere error handling en retry-logica. Soms moet je de architectuur aanpassen. Een gratis adviesgesprek kan helpen om te bepalen wat de beste aanpak is.

Hoe weet ik of mijn koppeling veilig genoeg is?

Belangrijkste checks: worden API-keys veilig opgeslagen (niet in de code)? Loopt data over een versleutelde verbinding (HTTPS)? Zijn er IP-whitelists waar mogelijk? Wordt er gelogd wie wat doet? Voor de meeste MKB-bedrijven is een standaard veiligheidsniveau voldoende, maar bij gevoelige data (bijv. in de zorg) zijn er extra eisen. Die bespreken we altijd vooraf.

Slotgedachte: betrouwbaarheid is geen luxe

Waar het op neerkomt: je kunt de mooiste koppeling bouwen, maar als die elke maand een keer uitvalt en je dat pas uren later merkt, schiet je er weinig mee op.

Betrouwbare integraties bouwen betekent niet dat ze nooit een error geven. Het betekent dat ze weten hoe ze met errors om moeten gaan. Dat ze automatisch retries doen. Dat ze je waarschuwen als er iets mis gaat. En dat je snel kunt achterhalen wat er gebeurde en waarom.

Bij bedrijven die dit goed geregeld hebben zie je een patroon: problemen worden in minuten opgelost in plaats van uren. Downtime daalt van 10+ incidenten per jaar naar 1-2. En belangrijker: ondernemers slapen beter omdat ze weten dat hun systemen gewoon blijven draaien.

Meer weten over hoe je dit voor jouw bedrijf regelt? Of twijfel je of jouw huidige koppelingen wel betrouwbaar genoeg zijn? Plan een vrijblijvend adviesgesprek in. We kijken dan samen naar jouw situatie en wat de beste aanpak is. Geen verplichtingen, gewoon een eerlijk verhaal over wat werkt en wat niet.

Voor meer praktische inzichten over systeemintegraties kun je ook onze kennisbank bekijken of lezen hoe andere MKB-bedrijven het hebben aangepakt in onze klantverhalen.