Ecommerce Integrations: How to Connect Your Store to an ERP So the Data Stays in Sync

Ask two vendors about ecommerce integrations and you will get two lists of connectors. Yet a store and an ERP drift apart over agreements, not connectors: which system is right about the price, what “available” actually means, who notices that the nightly import stopped halfway. An integration is simply those agreements, written into code. The decisions are made before the first line is written, and what the whole thing costs depends later on how hard it is to reach the ERP and what its data looks like. Below we walk through them one at a time, using mechanisms from projects we have built.

What is ERP integration for an online store

Ecommerce integrations are agreed data flows between an online store, an ERP and the company’s other systems, in which every piece of data has exactly one owner and it is clear when and through which route it travels. The ERP usually sits at the center of this setup, because that is where the company runs its stock and documents. This article is mainly about integrating an online store with an ERP.

The easiest way to see what an integration does is to look at what happens when a flow is set up wrong. At Pitstopparts, a full refresh of the supplier catalog took hours, and in that time the store could take money for goods the supplier no longer had. On Plastics’ B2B platform, looking up a customer by email address attached the order to a different company, and the ERP rejected it because the tax ID did not match. In both stories, each system worked correctly. What failed was the agreement on what should flow between them and when.

If you have an ERP that nobody in the company plans to replace, and a store that has to talk to it, the integration does all the work of making the two fit. A plugin handles the smallest part of it. Three decisions matter more: which system is the source of truth for which data, whether data flows right after a change or on a schedule, and what happens when the other side does not respond.

Which system is the source of truth for which data

In 2021, the Christmas tree seller FairyTrees sold mainly through marketplaces, ran a strongly seasonal business on Microsoft Dynamics NAV, which could only be reached over SOAP. Before the first line of integration code, the project document set out the split: NAV owns stock and documents, the PIM owns product content, Magento owns the offer and the price, and BaseLinker and Channable handle the marketplaces. A sheet like that looks like a formality until the day two systems show two different prices for the same product. Then it is immediately clear which one to fix.

That split is easy to turn into a template for your own project:

Filling in a table like this can turn up two surprises, both showing that an online store integration does not revolve around the store. The first: the source of truth for the offer can be a system the store has no influence on. At DESA, the catalog lives in the client’s CRM. Categories, variants and price zones are created there, and that is also where someone decides which products to reject. The catalog reaches the store through a scheduled import, first from the CRM to the PIM, then from the PIM to Magento, together with a price for each zone.

The second concerns stock, which in practice has two parts with different owners. The ERP knows the warehouse, while the store knows what it has already sold but not yet shipped. Magento calculates the salable quantity as the stock from its sources minus reservations for placed, unshipped orders. An integration that simply copies stock from the ERP to the store has to take both systems into account, or goods reserved an hour ago will show up as available again.

Since 2026, the invoice row in that table has a third participant. From February 1, all VAT payers in Poland receive invoices through KSeF, and the largest companies also issue them there. From April 1, everyone else issues them there too, and the smallest businesses have until the end of the year. The question of whether the store or the ERP issues the invoice now also decides which of them talks to KSeF.

Event or schedule: how fresh does the data need to be?

The method depends on how fresh the data has to be and how much a mistake costs, and the decision is made separately for each piece of data. How often does the store need to know what a product costs? And how often does it need to know how many are left? In the Plastics integration, the answers differ: prices come from the ERP once a day, while stock is synced in a separate run that detects what has changed and writes each change completely or not at all.

Splitting by company size (large stores on events, small ones on CSV files) does not help much here. A customer group’s price list can be a day old, because it rarely changes, so Canpol pulls it from the ERP as an XML file every night. Pitstopparts checks stock at the wholesaler through the supplier’s API only at the moment the order is placed, because a mistake means selling something that is not there.

Events have their own trap: you have to decide what counts as an event. At DESA, Magento sends a notification on every order change, while the client’s CRM needs four stages and not a single duplicate. So an integrator with a RabbitMQ queue sits between them and, out of all those notifications, lets each stage through exactly once. The queue alone does not give this protection. Queues deliver a message at least once, and after a dropped connection an unacknowledged message comes back, so it is the receiver that has to recognize the repeat.

There is also a third way: a delay chosen on purpose. The Bolero mobile app does not query Magento. It reads from a separate copy of the data that is rebuilt every night, and orders and payments go back from it to the store every few minutes. The store learns about an order with a slight delay, but app traffic puts no load on it, and the new channel does not duplicate the store’s logic. None of these approaches needs exotic infrastructure: Magento 2 has a built-in queue mechanism, but in production an external broker is recommended, for example RabbitMQ, plus separate processes that consume the messages, and someone has to make sure they keep running.

When something goes wrong, and how you find out

On July 20, 2026, Plastics’ ERP vendor switched off the old price and stock endpoints in production, the ones the store integration used. The integration had to move to a new one, a single endpoint instead of several. An ERP that nobody in the company plans to replace changes anyway.

So failures cannot be ruled out. What you can decide up front is what happens when one occurs. At DESA, when the CRM does not accept an order stage, the integrator has a resend panel, and nobody needs to call a developer to send the order again. A failing external service must not stop the store either: the customer should be able to buy even when a service around the store is down. And a long import that stops halfway should resume where it left off and recognize when the catalog has ended, instead of starting from scratch.

The other half of this decision is how you know that something broke at all. At one of our clients, integration monitoring runs on Grafana, Graylog and a custom logging system. Analyzing those logs showed that most entries were about orders the integration skipped on purpose, and that scheduled jobs overlapped. We planned to cut the unnecessary logging, so that a real error does not get lost among entries about nothing. Some dependencies are invisible until they break, like the mobile app login endpoint that disappeared together with a disabled module.

The most expensive integration error is the one that leaves no trace in the logs.

Access to the ERP sets the cost of integration

An ERP integration costs as much as access to the ERP does. That shows up in the analysis, before anyone names a price. In seven ERP integration projects we had seven different systems and seven different routes to the data:

• Microsoft Dynamics AX: SOAP with NTLM authentication, access over VPN,

• Vendo: REST API,

• Microsoft Dynamics NAV / Business Central,

• 1C: SOAP, with multi-currency settlements,

• Softlab: through BaseLinker as an intermediary,

• the client’s CRM, which holds the catalog,

• Navireo, alongside the InterCars wholesale API.

The toughest case on this list is Plastics: AX running on the company’s own servers, behind a VPN, with SOAP and NTLM. Before the integration passes on its first order, you have to set up the tunnel and the authentication, and then go through the whole cycle: order, customer, PDF invoice, shipment, separately for B2B and B2C, with the rule that an unpaid order does not get shipped.

The same feature list on an ERP with an open REST API is a completely different project.

So we check access with code before the decision is made. At MUVE, before the decision to migrate, we built a POC against the old system’s API: a short prototype meant to show whether the data could be pulled out of it. The exchange rate module, which was to replace manual price conversion between markets and connect rates from the OANDA API with the price import from the PIM, was preceded by a two-day POC. At Canpol, the analysis included separate integration workshops with the client’s team, alongside workshops on UX and features. We do not quote prices here, because without that analysis they would be guesswork. The pre-implementation analysis itself usually takes three to five weeks. After it, you know what has to be connected and through which route.

Data that is right for the ERP and wrong for the store

In the FairyTrees ERP, every color of a Christmas tree is a separate, independent product with its own SKU. From the ERP’s point of view, everything is fine: marketplaces need exactly these flat SKUs. A store that took that data as is would show the customer a separate product page for every color of the same tree, instead of one page with a variant picker. Nobody rebuilt the ERP for the store. The store makes up the difference: a variant group module with its own admin panel combines the independent SKUs into one product and makes sure filtering and category listings handle it correctly. The module has five years of development behind it. The cost of data that fits the store badly did not end on launch day.

A client that sells under several brands and through several companies showed a second, less visible kind of cost. Orders for several brands and companies landed in a single Channable account, and each company did its bookkeeping in a separate NAV instance. Which company served which sales channel was hard-coded in the integration. The fix required a rebuild: the company is now stored on the order document, the link between a channel and a company is configurable, historical orders were migrated to the new model, and a second Channable integration was added alongside.

Both cases follow the same pattern. Data or a decision that was fine at the start begins to cost money as the company adds channels, brands and companies. In ecommerce integrations, this part of the cost is the hardest to estimate, because on the day of the analysis it is not visible yet.

Off-the-shelf integrator or your own integration bus

You do not have to choose. At JKB, sales channels are handled by off-the-shelf tools, BaseLinker and Channable, and a custom order management system works between them and the ERP. Orders from BaseLinker, Channable and Magento go into it and become ERP documents, with each marketplace on its own account and separate logic for Amazon FBA and Etsy. Stock, prices, invoices and shipments flow the other way. The off-the-shelf tool does its job where the problem is typical, such as publishing listings on a marketplace, and custom code takes over where the client’s accounting begins.

An off-the-shelf integrator can also be the bus in projects we build. At Canpol, BaseLinker connects the Softlab ERP with Magento, and the same SKU appears in the store as two products, B2B and B2C, with separate stock sources. Such a setup is limited by its data model. At Bolero, bundle prices and invoices issued to a named person had to reach the order through a BaseLinker integration extended with custom code, and every such exception is something someone has to maintain afterwards.

At the other end is MUVE, which got its own integration with Allegro, Poland’s largest marketplace. The process did not fit the typical model: digital keys sent automatically after an order, multiple accounts, separate prices for each market, listings created from flags in the PIM, and Allegro price campaigns matched to products by EAN from a spreadsheet.

Then there is the bill. The subscription for an off-the-shelf integrator grows with sales: in BaseLinker you pay a fixed fee plus a separate fee for each order. The cost of your own bus depends mainly on how many systems have to be connected and how hard they are to reach. For a small or medium-sized store, BaseLinker is more than enough, and there is no point in building anything next to it. Your own bus starts to pay off where processes go beyond the typical model.

One of our clients has been running on the same integration bus for six years. The scale has grown over that time, and the architecture has not changed, because it was built for growth from day one. You design an integration for years, because that is how long you will be living with it.

Summary

Every system in a company has an owner. The ERP has its vendor and the accounting department, the store has its agency and the ecommerce team, and the space between them belongs to nobody, except the person who last fixed something there. Maybe that is why conversations about integration so often start with tools: you can buy a tool, but nobody sells responsibility for the middle. Someone on the company side has to treat that middle as their territory and know what moves through it. So who is watching the middle at your company?

If you want to see how these decisions look for your store and your ERP, book a free consultation. We will go through them one by one and tell you what they mean for the scope of the integration.