An ERP integration stopped being a technical side project a long time ago. It is the backbone of your commerce operation. And yet we still walk into projects where connecting an ERP, WMS or PIM to the webshop takes six months, while the real work during those months was never the programming. It was tracking down field names, emailing back and forth about who owns which value, and writing out mappings nobody dares to touch after go-live. That is exactly the part we automated with our own AI system. Below you will read how an integration actually works, where integrations break in practice, and why lead time today is driven far more by decisions than by code.
What is an ERP integration exactly?
An ERP integration is an automated connection between your ERP system and your webshop, in which both sides continuously share the same data: items, prices, inventory, orders, customers and invoices. Instead of someone retyping order data or importing a CSV every day, the exchange runs through the APIs of both systems, usually within seconds of an event.
That sounds simpler than it is, because an integration consists of three layers. The first is the connection: authentication, transport, error handling and respecting limits. The second is the translation, where the ERP data model is mapped onto your webshop. The third is the agreements: which system owns which field, and what happens when both sides change something at the same time.
The first layer is standard work that looks the same in every integration. The second layer is where an AI system makes the difference. The third layer is human work and will stay that way, no matter how good the models get.
ERP, WMS, PIM and OMS: who owns which field?
Most failed integrations did not fail on technology, they failed on ownership. Before a single line of code is written, it has to be clear which system owns the truth about which piece of data. Four systems compete for the same fields.
- ERP (Exact Online, AFAS, Microsoft Dynamics 365 Business Central, Odoo, SAP): finance, purchasing, item master, cost prices and invoicing. Usually the source of truth for item number, base price and tax code.
- WMS, the warehouse management system: physical stock, locations, batches, picking and shipping. The only place that knows what is actually on the shelf.
- PIM, the product information management system: product copy, translations, specifications, imagery and assortment per market. The source of truth for everything the customer reads and sees.
- OMS: order orchestration once you run multiple sales channels and warehouses and something has to decide where an order ships from.
The golden rule: every field has exactly one owner. The moment two systems are allowed to write the same field, it is not a question of whether things break but when. In its own architecture documentation for enterprise order management, Shopify describes three patterns you can choose from: an external OMS that leads and feeds Shopify a single available-to-sell number per SKU, a hybrid model, or Shopify itself as the orchestrator. All three work. What does not work is failing to choose.
Why a webshop integration works differently in 2026 than in 2020
If you have not opened the Shopify documentation in a few years, you are building integrations on foundations that are disappearing. Three things changed fundamentally.
First, REST is over. The REST Admin API has been a legacy API since 1 October 2024, and since 1 April 2025 all new public apps must be built on the GraphQL Admin API. An integration that still leans on REST endpoints today is technical debt with an expiry date.
Second, the limits are measured in cost rather than requests. The GraphQL Admin API works with calculated query costs: 100 points per second on standard plans, 200 on Advanced, 1,000 on Shopify Plus and 2,000 on Commerce Components. A single query may never exceed 1,000 points, and input arrays are capped at 250 elements. That stays abstract until you have to refresh a catalogue of 40,000 SKUs: a naive integration firing one mutation per item hits the ceiling within a minute on a standard plan. On Shopify Plus you get ten times the headroom, but even there a well built integration beats a fast one.
Third, there is now a mutation designed for exactly your situation. Shopify built productSet for the case where an external system is the source of truth, explicitly naming the ERP, the PIM, a spreadsheet or a custom database. You send the complete desired state of a product and Shopify makes its own data match it. Mind the flip side: list fields you leave out, such as variants, metafields and collections, get removed. So you always fill that mutation completely, never partially. For the initial load and large periodic updates you use bulk operations: you supply a JSONL file of at most 100 MB, Shopify processes it asynchronously and returns the result as a file. Since API version 2026-01 an app may run five of those bulk mutations at the same time per shop, where previously it was one.
The same principle applies to inventory on a smaller scale: write absolute quantities with inventorySetQuantities from the system that knows the truth, use inventoryAdjustQuantities only for deltas you are certain you will never miss, and run a periodic reconciliation alongside it.
Our approach: connecting systems with our own AI system
The reason integrations traditionally take months is rarely the complexity of the code. It is the sheer volume of boring, precise work: understanding hundreds of fields, lining them up, deciding on a transformation per field, documenting all of it, and only then building. That is exactly the kind of work language models are good at, provided you give them the right input and have the output checked by someone who understands it. We built our own system for that and use it in every integration project.
Step 1: everything known about the other system goes in
We feed the system everything that exists about the other side: the API documentation, an OpenAPI or WSDL file, a handful of real payloads, a CSV export from the ERP and the field list from the PIM. Even a legacy system without proper documentation works, as long as we have samples of real data. From that input the system builds a field inventory: which fields exist, what type they are, how often they are populated and which values actually occur. Those last two matter most, because documentation describes the intention while real payloads describe reality. The gap between them is where integrations die.
Step 2: the mapping arrives as a proposal, not an instruction
Next the system lines that inventory up against the Shopify data model: products, variants, metafields, inventory levels, orders, and for B2B also companies and company locations. For every field it makes a concrete proposal including the transformation required: prices from excluding to including VAT, weights from grams to kilos, language and currency codes, media URLs, and the question of whether something should become a metafield or a variant option. What comes out is a mapping document that we and your team review line by line. That phase used to cost weeks of workshops and now usually lands on the table within a day.
Step 3: code, tests and error handling in one pass
Once the mapping is approved, the system generates the transformation layer: typed code with validation per field, plus the infrastructure around it. That infrastructure is nearly identical in every integration and therefore perfect to automate: a queue, retries with increasing backoff, idempotency based on the webhook id, logging per record, and an overview of which items failed validation. At the same time it builds a test set from the real payloads of step 1, so we can run against data we already know before a single order passes through.
Step 4: the last stretch is human work, and that is the whole point
What our system does not solve: which price agreement applies to which B2B customer, what should happen on a partial delivery, whether the ERP or the WMS owns inventory, and whether product copy from the PIM may hit the storefront unfiltered. Those are not technical questions but business questions, and you cannot outsource them to a model. The difference with the old way is that our developers now spend almost all of their time on those questions instead of on the two hundredth field mapping. As a result the first working sync usually runs in a test environment within a week. The weeks after that go into edge cases, which is exactly where they belong.
An integration that stands up in days is not faster because less thinking went into it. It is faster because the thinking finally goes into the right things.
Five places where an ERP integration breaks in practice
These are the scenarios we run into most often when we take over an existing integration.
1. Two systems both writing inventory
The ERP pushes a full stock count overnight, the WMS pushes deltas during the day, and nobody wrote down who wins. It adds up during the day and no longer does the next morning. The fix is not smarter code but a decision: one system writes absolute quantities, the rest observe. On top of that a daily reconciliation compares counts and corrects deviations. Shopify recommends that reconciliation in its own enterprise documentation, and rightly so: drift is not an exception, it is a certainty.
2. Webhooks that answer too slowly
Shopify expects a 200 OK within five seconds and applies a one second connection timeout. If you try to write the order into the ERP inside that same request, you will not make it on a busy day. Shopify then retries with increasing intervals, and after persistent failures the subscription is eventually removed. First you get duplicate orders, then silent gaps. So return 200 immediately, put the message on a queue and process it afterwards. Deduplicate on the X-Shopify-Webhook-Id header and use X-Shopify-Event-Id to correlate deliveries from the same action. According to Shopify, a failure rate above 0.5 percent already warrants investigation.
3. The ERP knows item numbers, Shopify knows variants
An ERP thinks in individual items with their own number, Shopify thinks in products with options and variants. Which ERP items together form one product, and which field becomes the option value, is the single most important content decision of the entire project. Get it wrong and you will rebuild it later, including all the URLs and SEO value you lose along the way. Also keep the default limit of 2,048 variants per product in mind.
4. A first sync nobody tested at volume
Pushing forty thousand items through a synchronous API is not a matter of patience but of arithmetic. Test the initial load at production volume before you agree on a launch date, and use bulk operations instead of individual mutations. A bulk mutation also has to finish within 24 hours, otherwise it is stopped and you start over.
5. Nobody watches it until it breaks
Most integrations have no monitoring, only a mailbox receiving error messages nobody reads. The minimum you need: a counter on processed and failed messages per hour, an age alert on the queue, and a daily reconciliation report with the number of differences. An integration that stalls should be known within minutes, not when customer service calls.
Off-the-shelf connector or custom integration?
Not every situation calls for custom work, and we would rather not sell it when it is not needed. A ready-made connector is the right choice if you run a standard ERP such as Exact Online or AFAS, with standard fields, one market, one warehouse and no unusual pricing logic. For Exact we covered that route separately on our page about the Shopify Exact integration.
Custom becomes interesting the moment at least one of these applies:
- You run a custom or legacy ERP without a modern API.
- You have customer specific price agreements or volume tiers in B2B.
- You sell across multiple markets with their own assortment and translations.
- Your PIM leads on content and has to roll out per market.
- Your WMS handles partial deliveries, batches or dropshipping.
- The connector forces you to adapt your process to the software.
Our rule of thumb: a connector that covers 90 percent and leaves 10 percent manual work is more expensive than custom work as soon as that manual work returns daily. Calculate once what it costs per year in hours and errors, and the sum makes itself. If you are still on another platform, the moment to integrate is often the same moment as a migration from Magento to Shopify, because you are walking through your entire data model anyway.
What an integration project looks like
- 1Inventory. Which systems take part, which fields exist, and who owns which piece of data. Days rather than weeks, because the field inventory is built automatically.
- 2Mapping and sign-off. The per field proposal goes through your team line by line. This is where the decisions are made that are expensive to reverse later.
- 3Build and test sync. The integration runs on a development environment against real, anonymised data from your own systems.
- 4Shadow running. The integration runs along in production without writing, and we compare what it would do against what actually happens. This phase is often skipped and is precisely the one that prevents duplicate orders.
- 5Live with monitoring. Including daily reconciliation, alerts and a dashboard where you can see for yourself what passes through.
Frequently asked questions about ERP integrations
What is an ERP integration?
An ERP integration is an automated connection between your ERP system and your webshop, in which items, prices, inventory, orders and customer data are exchanged automatically through the APIs of both systems. The goal is a single source of truth per field, so nobody has to retype data.
How long does it take to build an ERP integration?
With us the first working sync usually runs in a test environment within a week, because the field inventory and the mapping are built automatically. Total lead time to go-live is then mostly determined by the number of exceptions in your process, the data quality in the ERP and how quickly decisions get made. Count on weeks rather than months, unless your data model needs cleaning up first.
What is the difference between an ERP, WMS and PIM integration?
They connect different kinds of truth. An ERP integration covers items, prices, orders and invoices. A WMS integration covers physical stock, locations and shipping. A PIM integration covers product content: copy, translations, specifications and imagery. In larger organisations all three run at once, with each system owning its own fields.
Can any ERP system be connected to Shopify?
In practice almost always, as long as there is an API, a database or an automated export available. Modern systems offer a REST or GraphQL API. Older systems we unlock through SFTP file exchange or a direct database connection. What does differ is the amount of work: the less the source system exposes, the more logic is needed on our side.
What does an ERP integration cost?
The price is driven by the number of fields, the number of directions being synchronised, the volume of exceptions in your process and the quality of your source data. A one-way inventory sync is a fraction of a two-way integration handling orders, invoices, customer specific prices and returns. We quote a fixed price after the inventory phase, so there is no open ended bill. You can find an indication of what a Shopify project costs on our Shopify engagements page.
What happens if the integration goes down?
With a well built integration nothing irreversible happens. Messages stay on the queue, get processed once service is restored, and idempotency makes sure a message that arrives twice does not create a second order. The daily reconciliation catches whatever still slipped through during the outage. What you want to avoid is an integration without a queue, because there the messages that arrived during the outage are gone for good.
Ready to connect your systems?
Do you run an ERP, WMS or PIM that does not talk to your webshop yet, or an existing integration that breaks too often? Tell us which systems you use and we will show you in the inventory phase exactly which fields can be connected and what that delivers. If you want to do the whole track properly in one go, have a look at Shopify webshop development as well, or get in touch.