Use Shopware ERP integrationto keep stock and ordersin sync

Data flow

Which data flows between Shopware and your ERP?

Between Shopware and an ERP, product master data, stock and prices typically flow from the ERP into the shop, orders and payment status flow from the shop into the ERP, and shipping and invoice data come back again. Articles on ERP integration describe it the same way.

The list on its own does not get you far. What matters more is a rule you write down before anyone touches code: each type of data has exactly one leading system. If someone in marketing changes a price directly in the shop while purchasing recalculates the same item in the ERP, the next sync overwrites one of those changes, and which one survives depends purely on the order in which the data arrives. So put the assignment in writing (a simple table of which shop field matches which ERP field is enough).

Customer data is the special case. New customers register themselves in the shop, terms and customer groups are often maintained in the ERP, and both sides have to recognise the same person even when they enter a new delivery address on their second order. That needs a shared key such as the customer number, otherwise you end up with duplicates. If you give resellers their own prices and customer groups, our article on Shopware B2B goes into more detail.

Routes

Which routes are there for a Shopware ERP integration?

A Shopware ERP integration can take four basic routes: a ready-made connector from the Shopware Store, middleware between the systems, a custom interface using the Admin API, or an app that learns about events in the shop through webhooks. You do not have to commit to exactly one, by the way. A connector for orders sits quite happily next to a small custom sync that handles the special cases it does not cover.

If your shop runs on Shopware Cloud, the choice gets shorter. According to Shopware only apps are supported there, so an integration that lives in the shop as a plugin is ruled out. Our article on whether to buy or build a Shopware plugin explains the difference between the two.

1. quick to startReady-made connectorA manufacturer or provider supplies the integration as an extension. You pay rent and get a fixed feature set, which has to match the way you work.
2. flexible mappingMiddlewareA separate integration layer between ERP and shop translates the fields. Useful when several systems are involved, such as ERP, marketplaces and shop.
3. full controlCustom interfaceA service reads and writes exactly the data you need through the Admin API. Maintenance and adjustments after updates are down to you or your developer.
4. event drivenApp with webhooksShopware reports events such as new or changed orders to an address you define. The sync then starts when something happens rather than at a fixed time.

Technology

What does the Shopware Admin API do for your ERP?

The Shopware Admin API is the interface through which external systems such as an ERP read and write products, orders, customers and other data. Shopware explicitly describes it as the surface for integrations, automation and data synchronisation, with read and write access to every entity.

You create access in the Administration under Settings, System, Integrations. That gives you an access ID and a secret key, which the ERP or the middleware uses to get a token via OAuth. Give each integration only the permissions the sync really needs, and create a separate one for every connected system. When a wrong stock figure turns up on a product later, you can then see which system wrote it and lock exactly that one access while your marketplace and shipping connections keep running.

For large volumes there is the sync endpoint. It accepts many write operations in one request, creates or updates records and can delete them too. If a single operation inside it fails, Shopware's documentation says the whole request is rolled back. That sounds like a detail, and in practice it is mostly an annoyance: one product with a faulty field holds up an entire batch of stock changes, which is why smaller batches with targeted retries have proved their worth. The indexing-behavior header lets you move indexing after an import into a queue, which takes load off the server during large imports. We build integrations like this on the Admin API as part of Shopware development at Scalableloops and test them on Shopware 6.6 and 6.7.

Scope

Shopware API: when do you need the Admin API, and when the Store API?

For integrations, the Shopware API comes in two parts: the Admin API is meant for systems working in the background, the Store API for everything customers see. Product search, cart, checkout and customer account all run through the Store API, for example for a custom frontend, and it authenticates with a public access key rather than OAuth.

That makes it the wrong route for an ERP, because it deliberately only returns what may be shown in the frontend. Setting stock, collecting orders or changing a status belongs in the Admin API.

If your sync fires a lot of requests in quick succession, rate limiting comes into play. Shopware has had a built-in rate limiter since version 6.4.6.0, and anyone sending too many requests gets a response with status code 429. If the interface does not catch that and try again later, data gets lost, and usually nobody notices until a customer asks where their tracking number is.

Orders

How do orders and their status get from Shopware into the ERP?

A Shopware ERP connection either collects orders at fixed intervals or gets notified through webhooks as soon as an order is created or changed. Webhooks are available for apps: when an event happens, Shopware sends a request to the address stored in the app, so the ERP does not have to keep asking every few minutes whether anything has changed.

The status deserves a close look, because an order in Shopware has more than one. Technically there are separate states for the order itself, for the payment and for the delivery, and each may only make certain transitions. So agree on which status in the shop triggers which step in the ERP. Should the warehouse already pick an order paid by bank transfer that has not arrived yet, or only once it is paid?

In the other direction, the ERP writes shipping and the tracking number back so the customer can see them in their account and in the shipping confirmation. The least trouble comes from a simple split where the ERP changes the delivery status, the shop changes the payment status, and neither system writes into the other's area.

Failure cases

Where do duplicate orders and wrong stock come from in Shopware inventory management?

Duplicate orders and wrong stock in Shopware inventory management almost always come from the same place: the gap between two syncs. Articles on the subject name the typical cases as delayed stock syncs that lead to selling more than is in the warehouse, partial returns, cancellations after dispatch, manual stock corrections and stock changes that happen in the middle of an order.

A unique key protects the ERP against duplicate orders. The interface remembers which order numbers it has already transferred and does not create the same number a second time. That catches the case you run into most often in practice: a sync breaks off halfway, starts again and fetches the same orders once more.

With stock, the order of events matters. If the ERP writes an absolute stock figure into the shop before it has processed the latest shop orders, those sales are missing from the number, and the shop sells goods that are already in a parcel on their way to someone else. So check when your shop reduces stock for an order and when the ERP overwrites it. Test it with an item that has just one unit left on the shelf (two orders placed shortly after each other quickly show whether the sequence is right).

For errors to be noticed at all, every transfer needs a log. Failed operations go into a queue, are retried and stay visible if the retry fails too. A sync that stops loudly is a nuisance. One that fails quietly costs you, weeks later, an inventory difference that nobody can explain any more.

Choosing

Shopware Lexware, JTL and other connectors: how do you spot the right one?

For Shopware and Lexware there are several extensions in the Shopware Store, and they show nicely why the description is worth reading carefully. Some send invoices and credit notes from the shop to Lexware Office, so they end up in accounting, while others pass orders into Lexware's inventory software. Both are called an integration, and if you only go by the name you will probably rent the wrong one.

JTL is similar. According to JTL, the JTL-Connector supports Shopware 6 and exchanges products, categories and customer data with JTL-Wawi in both directions. We mention both systems as examples, not as a recommendation, because which connector fits depends on the data list from the first section.

The same questions are worth asking of every candidate. Which types of data does it transfer, in which direction and how often? Does it support your Shopware version, and is it available as an app if you are on the cloud? Where do you see failed transfers? Can you try it with real data in a test environment before it goes live, and who adapts it when a new Shopware version comes out? What happens to extensions during a Shopware update is covered in a separate article.

To get started, or for that one big price change a year, the built-in tool is sometimes enough. Under Settings, Automation, Import/Export you can read products and other data in and out as CSV files using profiles. It is no substitute for an ongoing sync with your ERP, but as a bridge until the interface is ready it works fine. If you would like to go through your data list with us, book a free Shopware consultation.

Before the first quote

How to prepare your Shopware ERP integration

1. 01Write your data listNote for each type of data which system leads, which way it flows and how quickly it has to arrive. Add which shop field matches which ERP field, even if that is tedious the first time.
2. 02Play through the failure casesWrite down what should happen with a partial return, a cancellation after dispatch and an item with only one unit left. These three cases are what you measure every connector and every quote against.
3. 03Choose a route and test itGo through the ready-made connectors with your list first. If none is enough, have an integration built on the Admin API, and either way try it in a test environment before you switch over the live shop.