Shopware integration with your ERP, PIM and warehouse

What Shopware is and who runs it

Shopware is a German e-commerce platform. This page is about Shopware 6. There is a free Community Edition and there are paid plans, with extra features in the Commercial plugin. Shopware runs on your own server or at a hosting partner, and can run headless: your own frontend on the Store API, the standard administration behind it.

Shopware ships often. On October 1, 2026 it released 6.7.15.0 and 6.6.10.28 on the same day; the 6.6 line still gets patches. For an integration the point is that the Admin API has the same structure in both lines, and that the server limits are yours: Shopware sets no request limit of its own on the Admin API.

What connects to Shopware

Shopware owns orders and web customers. Products, prices and stock come from the ERP, the PIM or the warehouse. These are the flows we build as part of an e-commerce ERP integration:

An order has three states side by side: the order itself, the payment (transaction) and the delivery. Each has its own state machine, and a transition that is not defined in it is refused. The integration marks a delivery as shipped by calling a transition, not by overwriting a field. Order status mapping covers how statuses translate between systems.

How Shopware exposes data

Admin API, Store API and authentication

The Store API under /store-api/ serves the customer side: cart, checkout, a headless frontend. The Admin API under /api/ serves everything an integration does: products, orders, customers, bulk writes. Access runs through an integration created under Settings, System, Integrations, which gives an Access key ID and a Secret access key. The integration requests a bearer token with the client_credentials grant:

POST /api/oauth/token
Content-Type: application/json

{ "grant_type": "client_credentials",
  "client_id": "<Access key ID>",
  "client_secret": "<Secret access key>" }

The response holds the token and its lifetime in expires_in.

The limit is on tokens, not on requests

Shopware's built-in rate limiters protect logins, password resets and forms. One of them matters for an integration:

An integration that requests a new token for every call hits the oauth limiter after 10 calls in 10 seconds, and the same limiter then blocks administrators trying to log in. The integration stores the token and reuses it until shortly before expires_in. Beyond that, your server sets the ceiling: the Admin API is as fast as the database and the indexing underneath.

The Sync API

/api/_action/sync takes a list of operations in one request, each with an entity, an action (upsert or delete) and a payload of many records. An upsert with a known id updates the record; without an id, Shopware creates a new one. The integration therefore keeps the Shopware ID per item, or uses a resolver such as {"resolver": "product.number", "value": "10482"} to find a product by its number. After every write Shopware updates its indexes, which is the heavy part of a large import. The header indexing-behavior: use-queue-indexing moves that indexing to the background queue.

Worked through for a full stock and price update of 12,000 variants in batches of 500, a size we tune per store: 12,000 / 500 = 24 requests. With indexing in the request, each batch waits for the index update; with queue indexing, the 24 requests return quickly and the storefront catches up from the queue. Integration throughput has the general arithmetic.

Webhooks

Shopware sends webhooks to apps: an app's manifest names a URL per event, such as checkout.order.placed or product.written. Shopware's own design document of April 14, 2026 describes how delivery works today:

The error count is shared between webhooks with the same event and URL, so one failing endpoint can switch off webhooks for another app on the same URL. With the admin worker enabled, synchronous delivery has no retry and no log entry at all.

The integration treats a webhook as a signal, not as the source. A reconciliation run searches orders changed since the last successful run, so a missed webhook costs minutes, not an order. Webhooks are not a guarantee explains the pattern.

Where a Shopware integration gets stuck

Variants and inheritance

A variant in Shopware is a product with a parentId. Fields the variant does not set, such as the price, are inherited from the parent. A read without the header sw-inheritance: 1 returns null for those fields. An integration that takes that for empty writes a price on every variant, and from then on a price change on the parent no longer reaches the variants.

Color and size are options from a property group, with an ID per value and per installation: "Blue" has one ID on production and another on staging. Shopware separates options, which define a variant, from properties, which only describe it. An ERP color code that has no option in Shopware yet goes on a review list instead of failing the batch.

Net, gross and the default currency

A price has a net, a gross and linked per currency, and a product without a price in the system default currency is rejected. An ERP usually sends net only, so the integration computes gross: 89.50 net at 19 percent German VAT is 106.505, rounded 106.51; at 21 percent Dutch VAT it is 108.295, rounded 108.30. Which rate applies depends on the tax rule of the product. Money, tax and rounding covers rounding per line and per order.

Quantity breaks and customer group prices hang on a rule from the Rule Builder. For the cheapest price in listings and filters, Shopware considers at most 100 rules that match a customer. With more matching rules the product page still shows the right price, but sorting and the price filter in listings do not.

Visibility per sales channel

A product needs a visibilities entry per sales channel: 10 for link only, 20 for search, 30 for everywhere. Without it, the product exists in the administration and not in the store. The integration sets visibility when it creates a product and leaves it to you afterwards.

One stock number that Shopware also changes

product.stock is one number that Shopware keeps up to date itself: it goes down on an order and up on a cancellation. If the integration writes free stock from the ERP, that number has to account for Shopware orders the ERP has not received yet. The integration subtracts open Shopware orders that are not in the ERP before it writes. See which stock counts.

Systems we integrate with Shopware

Each system stores items, prices and stock in its own way. On the ERP side we connect Shopware to NetSuite, Business Central and Odoo; on the product data side to Akeneo. Other platforms with the same kind of setup: Magento, which also runs on your own server, and Shopify. All flows are listed on integrations.

We build the integration for a fixed price on your Shopware and your systems, then host, run and monitor it for a monthly fee. Before go-live it runs as a dry run: you see per product which price, stock and visibility it would set in Shopware, without changing anything. Tell us which Shopware version and systems you run.