Een koppeling tussen een ERP en een webshop is zelden moeilijk door de code. Het is moeilijk door alles eromheen: uitzoeken wat elk veld betekent, afspreken wie welke waarde beheert, en de mapping zo helder vastleggen dat niemand bang is om er na de livegang aan te komen. Dit artikel legt uit hoe een koppeling werkt, welke beslissingen eerst komen, en waar koppelingen meestal misgaan.
Wat een ERP-koppeling is
Een ERP-koppeling is een geautomatiseerde verbinding tussen je ERP en je webshop, zodat beide dezelfde artikelen, prijzen, voorraad, bestellingen, klanten en facturen delen. In plaats van dat iemand bestellingen overtypt of elke ochtend een spreadsheet importeert, wisselen de systemen gegevens uit via hun API's, meestal zodra er iets verandert.
Een koppeling heeft drie lagen. De verbinding: authenticatie, transport, foutafhandeling en de limieten van elke API. De vertaling: het datamodel van het ERP omzetten naar dat van de webshop. En de afspraken: welk systeem welk veld beheert, en wat er gebeurt als beide tegelijk iets wijzigen. De eerste laag ziet er in elk project ongeveer hetzelfde uit. De tweede is zorgvuldig, herhalend werk. De derde is een reeks zakelijke beslissingen, en geen enkel hulpmiddel neemt die voor je.
Wie welk veld beheert
De meeste koppelingen die mislukken, mislukken niet op techniek. Ze mislukken op eigenaarschap. Bepaal voordat er code wordt geschreven welk systeem voor elk gegeven de waarheid bevat. Meestal strijden vier systemen daarom:
- ERP (zoals Exact Online, AFAS, Microsoft Dynamics 365 Business Central, Odoo of SAP): financiën, inkoop, de artikelstam, kostprijzen en facturatie. Meestal de eigenaar van artikelnummers, basisprijzen en btw-codes.
- WMS, het warehouse management system: fysieke voorraad, locaties, batches, orderpicking en verzending. Het enige systeem dat weet wat er echt op de plank ligt.
- PIM, het productinformatiesysteem: beschrijvingen, vertalingen, specificaties en beeld per markt. De eigenaar van alles wat de klant leest en ziet.
- OMS, orderbeheer: bepalen vanaf waar elke bestelling wordt verzonden zodra je via meerdere kanalen of magazijnen verkoopt.
De regel is eenvoudig: elk veld heeft precies één eigenaar. Shopify beschrijft in zijn eigen documentatie over orderbeheer voor grote organisaties drie opzetten: een extern OMS dat leidt en Shopify per SKU één beschikbaar-voor-verkoop-aantal geeft, een hybride model, of Shopify zelf als regisseur. Elk van de drie werkt. Niet kiezen werkt niet.
Wat er aan de kant van Shopify veranderde
Een koppeling die een paar jaar geleden is ontworpen, kan rusten op fundamenten waar Shopify vanaf beweegt.
- GraphQL in plaats van REST. Shopify maakte de REST Admin API op 1 oktober 2024 tot legacy, en sinds 1 april 2025 moeten nieuwe publieke apps de GraphQL Admin API gebruiken. Een koppeling die vandaag op REST leunt, is technische schuld met een vervaldatum.
- Limieten gemeten in kosten. De GraphQL Admin API berekent voor elke query een prijs: een winkel op een standaardabonnement krijgt 100 punten per seconde, Advanced 200 en Shopify Plus 1.000, en één query mag niet boven de 1.000 punten uitkomen. Dat blijft abstract tot je een catalogus van tienduizenden producten één mutatie per keer bijwerkt.
- Een mutatie gebouwd voor een externe bron van waarheid. productSet neemt de volledige gewenste staat van een product en laat Shopify daarop aansluiten, wat goed past bij een ERP of PIM dat leidt. De keerzijde: lijstvelden die je weglaat, zoals varianten, worden verwijderd. Stuur dus altijd het volledige product, nooit een deel.
- Bulkoperaties voor volume. Voor de eerste vulling en grote updates verwerkt een bulkoperatie een JSONL-bestand op de achtergrond en levert het resultaat terug als bestand.
Voor voorraad geldt hetzelfde idee op kleinere schaal: laat het systeem dat de waarheid kent absolute aantallen schrijven, gebruik correcties alleen voor wijzigingen die je nooit mag missen, en stem regelmatig af.
Hoe wij het aanpakken
De meeste tijd in een koppelingsproject ging vroeger naar precies, herhalend werk: honderden velden begrijpen, naast elkaar leggen, per veld een omzetting kiezen en alles documenteren. Dat is werk waar onze eigen AI-tooling goed bij past, mits die de juiste input krijgt en een specialist alles controleert wat eruit komt.
1. Alles wat bekend is over het andere systeem gaat erin
API-documentatie, een OpenAPI- of WSDL-bestand, echte payloads, een export uit het ERP en de veldenlijst uit het PIM. Zelfs een ouder systeem zonder goede documentatie werkt, zolang er voorbeelden van echte data zijn. Daaruit bouwen we een veldinventaris: welke velden er zijn, van welk type, hoe vaak ze gevuld zijn en welke waarden er echt in staan. Documentatie beschrijft de bedoeling; echte data beschrijft wat er gebeurt. In het verschil tussen die twee gaan koppelingen mis.
2. De mapping komt als voorstel
Die inventaris wordt daarna naast het datamodel van Shopify gelegd: producten, varianten, metafields, voorraadniveaus, bestellingen en, voor B2B, bedrijven en hun locaties. Elk veld krijgt een concreet voorstel met de omzetting: prijzen met of zonder btw, grammen naar kilo's, taal- en valutacodes, en of iets een metafield of een variantoptie wordt. Jouw team en het onze lopen het regel voor regel door, in plaats van het in workshops vanaf nul op te bouwen.
3. Code, tests en foutafhandeling in één keer
Zodra de mapping is goedgekeurd, wordt de vertaallaag gegenereerd met validatie per veld, samen met wat elke koppeling nodig heeft: een wachtrij, herhaalpogingen met oplopende tussenpozen, bescherming tegen het dubbel verwerken van hetzelfde bericht, logging per record en een overzicht van wat niet door de validatie kwam. Uit de echte data van stap 1 wordt een testset gebouwd, zodat de eerste run draait op data die we al kennen.
4. De beslissingen blijven mensenwerk
Welke prijsafspraak geldt voor welke B2B-klant, wat er gebeurt bij een deellevering, of het ERP of het WMS de voorraad beheert, of PIM-teksten ongecontroleerd in de winkel mogen komen. Dat zijn zakelijke vragen, en die verdienen de tijd. Het punt van de rest automatiseren is dat onze developers hun aandacht hier besteden, niet aan het tweehonderdste veld.
Een koppeling is niet beter omdat hij snel is gebouwd. Hij is beter omdat het denkwerk op de juiste plekken terechtkwam.
Vijf plekken waar koppelingen misgaan
Twee systemen die voorraad schrijven
Het ERP stuurt 's nachts een volledige telling, het WMS stuurt overdag wijzigingen, en niemand heeft besloten wie wint. De oplossing is een beslissing, geen slimmere code: één systeem schrijft absolute aantallen en de rest leest mee. Een dagelijkse afstemming vergelijkt de tellingen en corrigeert de verschillen, want afwijkingen zijn geen uitzondering. Ze zijn een zekerheid.
Webhooks die te traag antwoorden
Shopify verwacht dat een webhook binnen enkele seconden wordt bevestigd. Schrijf je de bestelling in datzelfde verzoek naar het ERP, dan haal je dat op een drukke dag niet. Shopify probeert het opnieuw, en na herhaalde mislukkingen verwijdert het de koppeling. Eerst krijg je dubbele bestellingen, daarna stille gaten. Bevestig direct, zet het bericht in een wachtrij, verwerk het daarna, en gebruik het webhook-ID om dubbele berichten te negeren.
Artikelnummers tegenover varianten
Een ERP denkt in losse artikelen, elk met een eigen nummer. Shopify denkt in producten met opties en varianten. Bepalen welke artikelen samen één product vormen, en welk veld de optie wordt, is de belangrijkste inhoudelijke beslissing van het project. Doe je dat verkeerd, dan bouw je het later opnieuw, inclusief de URL's en vindbaarheid die eraan vastzitten.
Een eerste synchronisatie die nooit op volume is getest
Een hele catalogus artikel voor artikel door een API duwen is geen kwestie van geduld maar van rekenen. Test de eerste vulling op echt volume voordat je een lanceerdatum afspreekt, en gebruik bulkoperaties in plaats van losse mutaties.
Niemand die meekijkt
Veel koppelingen hebben geen monitoring, alleen een mailbox vol foutmeldingen die niemand leest. Het minimum: een telling van verwerkte en mislukte berichten, een melding als de wachtrij stilvalt, en een dagelijks afstemmingsrapport. Als een koppeling stokt, wil je dat van de koppeling horen, niet van de klantenservice.
Een standaardconnector of een koppeling op maat?
Niet elke situatie vraagt om maatwerk. Een standaardconnector is de juiste keuze bij een standaard-ERP met standaardvelden, één markt, één magazijn en geen bijzondere prijslogica. Een koppeling op maat wordt interessant zodra een of meer van deze punten gelden:
- Een ouder of eigen ERP zonder moderne API.
- Klantspecifieke prijzen of staffels in B2B.
- Meerdere markten, elk met een eigen assortiment en vertalingen.
- Een PIM dat per markt leidend is voor content.
- Een WMS dat deelleveringen, batches of dropshipping afhandelt.
- Een connector die je proces dwingt zich naar de software te voegen.
Een bruikbare toets: reken uit wat het handwerk dat een connector laat liggen per jaar kost aan uren en fouten. Stap je toch al over naar een ander platform, dan is dat meestal het moment, omdat je het hele datamodel dan al doorloopt. We schreven apart over wat je controleert als je webshop van Lightspeed naar Shopify verhuist.
Hoe een project verloopt
- Inventarisatie. Welke systemen meedoen, welke velden er zijn, en wie wat beheert.
- Mapping en akkoord. Het voorstel per veld gaat regel voor regel langs je team. Hier vallen de beslissingen die later duur zijn om terug te draaien.
- Bouwen en testen. De koppeling draait in een ontwikkelomgeving op echte, geanonimiseerde data uit je eigen systemen.
- Schaduwdraaien. De koppeling draait mee in productie zonder te schrijven, en we vergelijken wat hij zou doen met wat er echt gebeurt. Deze stap wordt vaak overgeslagen, en juist die voorkomt dubbele bestellingen.
- Live, met monitoring. Dagelijkse afstemming, meldingen, en een overzicht waarin je zelf ziet wat er doorheen gaat.
Veelgestelde vragen
Kan elk ERP aan Shopify worden gekoppeld?
Bijna altijd, zolang er een API, databasetoegang of een geautomatiseerde export is. Moderne systemen bieden een REST- of GraphQL-API; oudere systemen zijn te koppelen via bestandsuitwisseling over SFTP of een directe databaseverbinding. Wat verschilt, is de hoeveelheid werk: hoe minder het bronsysteem prijsgeeft, hoe meer logica er tussenin nodig is.
Hoe lang duurt een koppeling?
Dat hangt af van het aantal systemen, de uitzonderingen in je proces en de kwaliteit van de data in het ERP. Zodra de inventarisatie die helder heeft gemaakt, leggen we de planning per fase vast.
Wat bepaalt de kosten?
Het aantal velden, of data één kant of twee kanten op gaat, de uitzonderingen in je proces en de kwaliteit van de brondata. Een eenrichtingssynchronisatie van voorraad is een ander project dan een tweerichtingskoppeling met bestellingen, facturen, klantprijzen en retouren. Na de inventarisatie krijg je een voorstel voor jouw situatie.
Wat gebeurt er als de koppeling uitvalt?
Bij een goed gebouwde koppeling niets onomkeerbaars. Berichten wachten in de wachtrij en worden verwerkt zodra de verbinding terug is, de bescherming tegen dubbele berichten zorgt dat een bericht dat twee keer binnenkomt geen tweede bestelling maakt, en de dagelijkse afstemming vangt op wat er toch tussendoor glipte. Zonder wachtrij zijn de berichten die tijdens de storing binnenkwamen verloren.
Je systemen koppelen
Heb je een ERP, WMS of PIM dat nog niet met je webshop praat, of een koppeling die te vaak misgaat? Vertel ons welke systemen je gebruikt. Koppelingen horen bij hoe wij webdevelopment aanpakken, en de eerste stap is altijd de inventarisatie: welke velden te koppelen zijn, en wie elk veld beheert.