Een webshop koppelen aan je ERP klinkt eenvoudig: voorraad in, orders uit, klaar. In de praktijk loopt 60% van die integraties uit op meer problemen dan ze oplossen. Hier zijn de 5 valkuilen die we steeds weer zien — en hoe je ze omzeilt.
Valkuil 1: Realtime sync waar het niet hoeft
"Alles realtime" klinkt mooi. Maar realtime synchroniseren betekent: zware API-load, kwetsbaarheid bij netwerk-issues, en moeilijk debuggen. Bovendien levert het zelden échte business waarde.
Wat werkt beter:
- Voorraad: elke 5-15 minuten batch update is genoeg voor 95% van shops
- Orders: realtime push naar ERP (event-driven)
- Producten: dagelijks batch, of on-demand bij wijziging
- Klanten: bij eerste order, daarna op verandering
Vraag jezelf bij elke datastroom: wat is het écht acceptabele tijdsverschil? Meestal is het ruimer dan je denkt.
Valkuil 2: Geen idempotentie ingebouwd
Wat gebeurt er als je integratie een order tweemaal stuurt vanwege een netwerkfout? Bij 90% van de implementaties: dubbele order in ERP. Klant krijgt twee facturen. Chaos.
De oplossing is idempotente endpoints: elke API call krijgt een unieke ID. Tweede call met zelfde ID? ERP herkent het en doet niets. Klinkt simpel, maar 80% van de teams bouwt dit niet in tot het misgaat.
"We hebben er een gehad waar één Black Friday ochtend 340 dubbele orders ontstonden door een netwerkflapje. 3 dagen handmatig opruimen. Idempotency-key in de header had dit voorkomen."
Valkuil 3: Gebrek aan retry-logica
API's falen — netwerk, rate limits, timeouts. Een goede integratie heeft:
- Exponential backoff — eerste retry na 1 sec, dan 2, dan 4, dan 8
- Maximum retries — na 5 pogingen stopt het en wordt een mens gewaarschuwd
- Dead letter queue — gefaalde calls worden bewaard voor handmatige review
- Circuit breaker — als een endpoint 10 keer faalt, even stoppen voordat je de hele pipeline blokkeert
Zonder dit framework: je krijgt random missende data en niemand weet waar het misging.
Valkuil 4: Logging zonder context
"Order sync failed" — okay, welk order? Welk endpoint? Welke payload? Welke timestamp? Veel integraties loggen wel iets, maar niet bruikbaar.
Een goede logregel bevat:
- Correlation ID (voor tracing over systemen)
- Tijdstempel (UTC)
- Source en target endpoint
- Payload-hash (geen complete data — privacy)
- Status code en response
- Retry-count
Met deze velden in een centrale log (Elastic, Datadog, Loki) los je 80% van issues op in 10 minuten in plaats van 3 uur grasduinen.
Valkuil 5: Geen testbare integratie-laag
Veel teams bouwen integraties direct in business-code. Resultaat: kun je niet unit-testen, kun je niet mocken voor staging, en bij een ERP-versie-upgrade moet je productie aanpassen om iets te checken.
Beter: een anti-corruption layer. Je business-code praat met een interne service. Die service vertaalt naar ERP-API. Je kunt:
- De ERP-laag mocken in tests
- ERP-versies upgraden zonder business-code raken
- Eventueel later van ERP veranderen zonder al je code te herschrijven
De gouden regel
Een integratie is geen feature. Het is een systeem dat onderhoud, monitoring, alerting en documentatie nodig heeft. Bouw je het als feature, dan is het binnen een jaar een blackbox die niemand durft aan te raken.
Hulp nodig bij een complexe webshop-ERP integratie? Wij hebben 100+ integraties geleverd — van Shopify-Exact tot Magento-SAP. We weten waar de putten liggen.
Lees ook: de specifieke valkuilen rond webhooks en de architectuurkeuze die je hierin maakt.