Connecting Shopware to your ERP, PIM and marketplaces
An ERP integration for a webshop almost always starts small. One script that pushes articles into Shopware and one that sends orders back. That works, right up until a PIM is added, a second warehouse and a marketplace.
At that point the question is no longer how you connect system X to Shopware, but how you keep this landscape manageable. That is a different question, with a different answer.
.png)
Why point-to-point integrations run out of road
Every direct connection between two systems makes sense on its own. The problem is the count. With three systems you have a handful of connections, with seven the number climbs quickly, and every connection has its own credentials, its own data fields, its own retries and its own failures.
What goes wrong is predictable:
- Nobody sees the whole picture: an order is stuck somewhere unfindable.
- Every change touches several scripts: one field, five edits.
- Error handling differs per connection: an email, a log file or nothing.
- Knowledge sits with one person: usually whoever built it first.
- Re-running is frightening: nobody risks duplicate orders.
At that point we would rather build an integration layer than add another connection. On-premise Shopware keeps control of the store itself with you, and in between you put one platform that translates, validates and records what happened.
Which systems you connect, and what flows between them
The systems vary per company, but the pattern is remarkably stable. These are the seven places data comes from or has to go to, and what moves between Shopware and that system.
ERP
Articles, prices and tiers, stock, customers, orders, invoices and credit notes. Usually the source of truth for your financial data.
PIM
Product copy, specifications, media, categories, translations and variants, kept apart from the administration in your ERP.
WMS
Stock movements, pick and pack status, shipping confirmations and returns. Often the flow that can wait the least.
PSP
Payment status, refunds and reconciliation with invoicing, so your shop and your administration tell the same story.
Marketplaces
Catalogue and price out, orders and cancellations in, and stock that has to add up in both directions.
Marketing and customers
Customer profiles, segments, order history, subscriptions and consent, with one leading system per field.
Monitoring and errors
Readable error messages, retries and alerting, so you see a stalled sync before your customer calls.
Who owns which data
This is the question that comes before the technology, and the one most often skipped. For every piece of data, one system has to be the source and the rest follow. If two systems are both allowed to change the same price, sooner or later you get differences nobody can explain.
The ERP usually leads on prices, stock and financial data. The PIM leads on product information, media and translations. Shopware leads on everything that happens in the store: content pages, customer accounts and the order at the moment it is placed.
Customer data is often the hardest, because the ERP, the shop and the marketing system all want to keep their own version of it. That is why we record the source, the direction and the frequency per field before anything is built. It costs a few sessions and it saves months of argument later.
Only after that does it become a technology question. An integration layer, also called an iPaaS, puts one platform between your systems instead of wiring everything directly to everything else. Each system talks only to that layer, and that layer translates, validates, records what happened and retries when something fails.
That delivers three concrete things. You get one place to see which message was processed when and what failed. You can replace a system without rebuilding the rest, because only its one connection to the layer changes. And the mapping of data fields becomes configuration instead of code inside somebody's script.
Memo works with Alumio for this, an integration platform we partner with. For product information, Ergonode is one of the PIM systems we work with, precisely because it makes that split between source and consumer explicit.
.png)
What a well-built integration delivers operationally
With any integration, keep asking what happens when it fails, because that is where the difference lies. Does a failed message stay put with a readable error and the original payload attached, or does it disappear? Can you replay a message or a whole batch without creating duplicate orders or duplicate invoices? Do you find out within minutes that the stock sync has stalled, or do you hear it from a customer who ordered too much?
Set the frequency per flow as well, rather than putting everything on the same rhythm. Stock usually needs to be near real time, invoices are fine hourly. And check whether the mapping is documented and visible in the platform, instead of hidden in code that only one person understands.
In practice we most often end up with Exact Online, Microsoft Dynamics and AFAS. We have built integrations for those and know where their quirks are. If you run something else, that is rarely a problem: what matters is the data flows and whether the package has a usable API, not the name on the box.
With a marketplace integration, the trap is nearly always stock. The same article sits in your own shop and on two marketplaces, and the question is how quickly and how often you synchronise without overselling. That is also the honest answer to what an integration delivers: less manual re-keying, fewer wrong stock levels, and a landscape you can extend without rebuilding everything.
What that looks like in practice
For XXL Nutrition, Memo built a scalable commerce ecosystem with the integration landscape at its centre, including the connection to the Cayenne WMS via Alumio. That is exactly the scenario where an integration layer pays for itself: high volume, several systems and a warehouse process that cannot wait for a manual step.
At Boomlab, a laboratory wholesaler in the Benelux, Shopware runs in combination with Alumio in a B2B setting. There it is less about volume and more about correctness: customer-specific agreements, articles that have to be exactly right, and ordering processes that match how buyers actually work.
That brings you to the last connection. Customer-specific prices, tiers, credit limits, organisational structures and quotes nearly all originate somewhere in your ERP, and how you model those in Shopware determines how straightforward the integration becomes. So read the Shopware B2B page as well, where we cover B2B Components and what that means for complex customer structures.
What such a project costs depends on the number of data flows, how clean your data is and how many exceptions you have agreed with customers. How those costs break down is set out on the costs page. Bring a list of your systems to a first conversation, and together we map your data flows and who owns which kind of data.
Frequently asked questions
What does an ERP integration for a webshop cost?
It depends on the number of data flows, how clean your data is and how many exceptions you have agreed with customers. One flow of articles and stock is a different project from a full landscape with orders, invoices and returns. How those costs break down is set out on the costs page.
Do I need a PIM system alongside my ERP?
If your product information stops at article number, price and stock, usually not. As soon as you work with rich content, multiple languages, variants and several sales channels, yes. An ERP is built for administration, not for product experience, and you feel that difference the moment marketing and purchasing want to manage the same fields.
What exactly is an iPaaS?
An integration platform as a service: one layer between your systems that fetches, translates, validates and forwards data, with logging and retries. Instead of ten direct connections, every system talks only to that layer. It makes failures visible and systems replaceable.
Can Shopware connect to marketplaces?
Yes. The challenge is not the connection itself but the rules: how much stock you reserve per channel, how often you synchronise, and which system leads on price. You settle those choices before you build, otherwise you sell articles you no longer have.
Who owns customer data once everything is connected?
You decide, and it is one of the first things to write down. Often the ERP leads on invoicing details and the shop on account details and preferences. Without that agreement, two systems overwrite each other's changes and no version is correct any more.