An integration between an ERP and a webshop is rarely difficult because of the code. It is difficult because of everything around it: finding out what each field means, agreeing who owns which value, and writing the mapping down so clearly that nobody is afraid to touch it after launch. This article explains how an integration works, which decisions come first, and where integrations tend to break.
What an ERP integration is
An ERP integration is an automated connection between your ERP and your store, so that both share the same items, prices, stock, orders, customers and invoices. Instead of someone retyping orders or importing a spreadsheet every morning, the systems exchange data through their APIs, usually as soon as something changes.
It has three layers. The connection: authentication, transport, error handling and the limits of each API. The translation: mapping the ERP's data model onto the store's. And the agreements: which system owns which field, and what happens when both change something at once. The first layer looks much the same in every project. The second is careful, repetitive work. The third is a set of business decisions, and no tool makes those for you.
Who owns which field
Most integrations that fail do not fail on technology. They fail on ownership. Before any code is written, decide which system holds the truth for each piece of data. Usually four systems compete for it:
- ERP (such as Exact Online, AFAS, Microsoft Dynamics 365 Business Central, Odoo or SAP): finance, purchasing, the item master, cost prices and invoicing. Usually the owner of item numbers, base prices and tax codes.
- WMS, the warehouse management system: physical stock, locations, batches, picking and shipping. The only system that knows what is actually on the shelf.
- PIM, the product information system: descriptions, translations, specifications and images per market. The owner of everything the customer reads and sees.
- OMS, order management: deciding where each order ships from once you sell through several channels or warehouses.
The rule is simple: every field has exactly one owner. Shopify's own documentation on enterprise order management describes three set-ups: an external OMS in charge that gives Shopify one available-to-sell number per SKU, a hybrid model, or Shopify itself as the orchestrator. Each of them works. Not choosing does not.
What changed on Shopify's side
An integration designed a few years ago may rest on foundations Shopify is moving away from.
- GraphQL instead of REST. Shopify marked the REST Admin API as legacy on 1 October 2024, and since 1 April 2025 new public apps must use the GraphQL Admin API. An integration that leans on REST today is technical debt with a date on it.
- Limits measured in cost. The GraphQL Admin API calculates a cost for every query: a store on a standard plan gets 100 points per second, Advanced 200 and Shopify Plus 1,000, and a single query cannot exceed 1,000 points. That stays abstract until you refresh a catalogue of tens of thousands of products one mutation at a time.
- A mutation built for an external source of truth. productSet takes the complete desired state of a product and makes Shopify match it, which suits an ERP or PIM that leads. The flip side: list fields you leave out, such as variants, are removed. Always send the complete product, never part of it.
- Bulk operations for volume. For the first load and for large updates, a bulk operation processes a JSONL file in the background and returns the result as a file.
For stock, the same idea applies on a smaller scale: let the system that knows the truth write absolute quantities, use adjustments only for changes you can never afford to miss, and reconcile regularly.
How we approach it
Most of the time in an integration project used to go into precise, repetitive work: understanding hundreds of fields, lining them up, choosing a transformation for each one and documenting it all. That is work our own AI tooling suits well, as long as it gets the right input and a specialist checks everything it produces.
1. Everything known about the other system goes in
API documentation, an OpenAPI or WSDL file, real payloads, an export from the ERP and the field list from the PIM. Even an older system without proper documentation works, as long as there are samples of real data. From that we build a field inventory: which fields exist, their types, how often they are filled and which values actually occur. Documentation describes the intention; real data describes what happens. The gap between the two is where integrations go wrong.
2. The mapping arrives as a proposal
That inventory is then lined up against Shopify's data model: products, variants, metafields, stock levels, orders and, for B2B, companies and their locations. Every field gets a concrete proposal with its transformation: prices with or without VAT, grams to kilos, language and currency codes, and whether something becomes a metafield or a variant option. Your team and ours review it line by line, instead of building it up from nothing in workshops.
3. Code, tests and error handling together
Once the mapping is approved, the transformation layer is generated with validation for every field, along with what every integration needs: a queue, retries at increasing intervals, protection against processing the same message twice, logging per record and an overview of what failed validation. A test set is built from the real data of step 1, so the first run is against data we already know.
4. The decisions stay human
Which price agreement applies to which B2B customer, what happens on a partial delivery, whether the ERP or the WMS owns stock, whether PIM copy may reach the storefront unchecked. These are business questions, and they deserve the time. The point of automating the rest is that our developers spend their attention here, not on the two-hundredth field.
An integration is not better because it was built quickly. It is better because the thinking went into the right places.
Five places where integrations break
Two systems writing stock
The ERP sends a full count overnight, the WMS sends changes during the day, and nobody decided who wins. The fix is a decision, not cleverer code: one system writes absolute quantities and the others read. A daily reconciliation compares counts and corrects the differences, because drift is not an exception. It is a certainty.
Webhooks that answer too slowly
Shopify expects a webhook to be acknowledged within seconds. Write the order into the ERP inside that same request and, on a busy day, you won't make it. Shopify retries, and after repeated failures it removes the subscription. First come duplicate orders, then silent gaps. Acknowledge straight away, put the message on a queue, process it afterwards, and use the webhook ID to ignore duplicates.
Item numbers versus variants
An ERP thinks in separate items, each with its own number. Shopify thinks in products with options and variants. Deciding which items together form one product, and which field becomes the option, is the most important content decision in the project. Get it wrong and you rebuild it later, along with the URLs and search visibility attached to it.
A first sync never tested at volume
Pushing a whole catalogue through an API one item at a time is not a matter of patience but of arithmetic. Test the first load at real volume before agreeing a launch date, and use bulk operations rather than individual mutations.
Nobody watching
Many integrations have no monitoring, only a mailbox of error messages nobody reads. The minimum: a count of processed and failed messages, an alert when the queue stops moving, and a daily reconciliation report. If an integration stalls, you should hear it from the integration, not from customer service.
A ready-made connector or a custom integration?
Not every situation needs custom work. A ready-made connector is the right choice for a standard ERP with standard fields, one market, one warehouse and no unusual pricing. A custom integration starts to make sense when one or more of these apply:
- An older or custom ERP without a modern API.
- Customer-specific prices or volume tiers in B2B.
- Several markets, each with its own assortment and translations.
- A PIM that leads on content per market.
- A WMS that handles partial deliveries, batches or dropshipping.
- A connector that forces your process to fit the software.
A useful test: work out what the manual work a connector leaves behind costs in hours and errors over a year. If you are changing platforms anyway, that is usually the moment to do it, because you are going through the whole data model already. We wrote separately about what to check when you move a store from Lightspeed to Shopify.
How a project runs
- Inventory. Which systems take part, which fields exist, and who owns what.
- Mapping and sign-off. The proposal for each field goes through your team line by line. This is where the decisions are made that are expensive to reverse.
- Build and test. The integration runs in a development environment against real, anonymised data from your own systems.
- Shadow running. The integration runs alongside production without writing, and we compare what it would do with what actually happens. This step is often skipped, and it is the one that prevents duplicate orders.
- Live, with monitoring. Daily reconciliation, alerts, and a view where you can see what passes through.
Frequently asked questions
Can any ERP be connected to Shopify?
Nearly always, as long as there is an API, database access or an automated export. Modern systems offer a REST or GraphQL API; older systems can be connected through file exchange over SFTP or a direct database connection. What differs is the amount of work: the less the source system exposes, the more logic is needed in between.
How long does an integration take?
That depends on the number of systems, the exceptions in your process and the quality of the data in the ERP. Once the inventory has made those clear, we set the timeline per phase.
What determines the cost?
The number of fields, whether data flows one way or both ways, the exceptions in your process and the quality of the source data. A one-way stock sync is a different project from a two-way integration with orders, invoices, customer prices and returns. After the inventory you get a proposal for your situation.
What happens if the integration goes down?
With a well-built integration, nothing irreversible. Messages wait on the queue and are processed once the connection is back, duplicate protection makes sure a message that arrives twice does not create a second order, and the daily reconciliation catches anything that slipped through. Without a queue, the messages that arrived during the outage are lost.
Connecting your systems
Do you run an ERP, WMS or PIM that doesn't talk to your store yet, or an integration that breaks too often? Tell us which systems you use. Integrations are part of how we approach web development, and the first step is always the inventory: which fields can be connected, and who owns each one.