Shopware 6 & PIM: Connect Product Data Cleanly Instead of Maintaining It by Hand

Most Shopware projects start with a sensible decision: product data is maintained directly in the shop. For one channel, one language and a manageable range, that is exactly right. Two years later, things look different. A marketplace comes along, then a second country, a dealer portal and a catalogue. Anyone still “just maintaining it in the shop” at that point is really maintaining it in five places at once.

Our thesis: Shopware 6 is an excellent sales and output system — but it is not an editorial system for product data across multiple channels. As soon as more than one channel depends on the same data, maintenance belongs in a PIM as the single source of truth. Shopware then receives the data cleanly, automatically and only with the changes. You maintain once and publish everywhere.

In this article you get a fair assessment of Shopware’s built-in tools, a reference architecture, a field mapping table with the actual Shopware fields, the integration process in seven steps and a readiness checklist.

Why Shopware’s built-in tools reach their limits

Let’s start with the honest part: Shopware 6 brings a lot to the table for product data. Anyone who plays that down is selling you a PIM for the wrong reasons.

• Properties and variants. Filterable characteristics are set up as properties. Variant-defining characteristics such as colour or size become options, from which Shopware generates variants. Variants are child products and inherit any values they don’t define themselves from the parent product.
• Custom fields. For anything the standard model doesn’t cover, there are custom fields with types such as text, number, date, selection or media.
• Multiple languages and sales channels. Languages can inherit from one another, and products can be made visible per sales channel.
• Import/Export. The module imports CSV files via profiles that define which column ends up in which field. It offers a dry run and an error file containing the faulty records.
• AI support. From the Rise plan upwards, Shopware includes AI features (Shopware Intelligence, referred to as AI Copilot in the documentation) that, among other things, draft product descriptions and suggest properties based on a description text.

For a shop as the only channel, that is often enough. The limits don’t lie in a single feature but in the purpose of the system: Shopware is built to sell and publish products, not as an editorial system in which product data is enriched and approved for many recipients. Typical friction points:

• The data is built around the shop. Shopware can export feeds to price portals via product comparison sales channels and connect marketplaces via Multichannel Connect (a separate add-on offering). But a print catalogue, dealer portal or data deliveries to trading partners often need the same data in a different structure. Without a central source outside the shop, copies emerge — and copies drift apart.
• CSV imports are manual work with pitfalls. Someone has to create the file, upload it and work through the error file. According to the Shopware documentation, an import can only add information, not remove it. An existing sales channel assignment, for example, cannot be removed via import.
• Supplier data arrives raw. Formats, units and spellings from suppliers need to be standardised before they are allowed into the shop.
• Many hands, no approval. Product management, marketing, translation and IT all work on the same items. Without a status model and owners per attribute group, nobody knows which version is ready to sell.
• Translations quietly fall back. Language inheritance is convenient. If a translation is missing, the shop shows the text of the inherited language without any indication. In the admin you can spot the gap by greyed-out values, but only field by field and item by item.

Whether these points hurt is not a question of shop size but of the number of channels. We cover the fundamental question in Is there even a need for a PIM besides the online store?, and the B2B angle with customer groups and pricing logic in Shopware B2B: B2B Suite or B2B Components?

Architecture: PIM → Shopware

A clean integration follows one simple principle: every type of data has exactly one leading system, and data flows in one direction only. For product data, the chain looks like this:

Sources (ERP, suppliers, photography, translation) → PIM (maintenance, enrichment, checks, approval) → integration layer (mapping, transformation, delta, error handling) → Shopware 6 (Admin API) → storefront and other sales channels

The middle layer is what matters: it translates between the PIM data model and the Shopware data model. Technically, it writes via the Admin API, which Shopware explicitly intends for backend integrations and data synchronisation. For larger data volumes, the Sync API bundles many write operations and different entities into a single request.

Who leads? Data ownership

The most common mistake in integration projects is organisational: two systems both consider themselves the leading system for the same fields. So before writing a single line of code, settle who owns what. The split below is a proven pattern, not a rule.

Three ways to build the bridge

There are three common options for the integration layer. None is better across the board.

1. Ready-made connector from the Shopware Store. Extensions exist for widely used PIM systems. Quick to get going if your data model is close to the standard; depending on the connector, you may hit limits with custom fields, special logic or multiple target systems.
2. Middleware between the systems. A data hub handles mapping, transformation, delta detection and error handling, and can serve other systems too. Robust in complex landscapes, but needs operation and monitoring.
3. Custom integration against the Admin API. Maximum freedom — but you build error handling, retry logic and logging yourself. Makes sense if you already have an integration team.

How publishing to many channels works in principle is explained in Syndication of product data.

Field mapping: from PIM attribute to Shopware field

Mapping is the heart of the integration. The table shows the key fields of a Shopware 6 product, with the admin label and the technical name from the Admin API. Five fields are mandatory when creating a product: name, product number, tax rate, price and stock.

The most important mapping decision concerns the middle rows: property, option or custom field? As a rule of thumb: what your customers select is an option. What they filter or compare is a property. What they only read belongs in a custom field. Set up every technical attribute as a property and you bloat filters and variant logic. Push everything into custom fields and you lose filterability.

The integration process in 7 steps

An integration project almost always follows the same sequence. Skip a step and it will come back to bite you at the latest on the first delta run.

1. Define data ownership. Write down the leading system for each type of data (see the table above) and agree it with the ERP, shop and product teams.
2. Decide the data model in Shopware. Define which attributes become properties, options or custom fields, which languages and sales channels are served and how variants are structured.
3. Specify the mapping. Every PIM attribute gets a target field, a transformation rule (unit, format, value list) and a rule for empty values.
4. Clarify keys and identities. The product number is the business key. On top of that, decide how media, property values and categories are uniquely recognised, so that a second run updates rather than duplicates.
5. Run the initial load. The first full run transfers the entire range. For large data volumes, the Shopware documentation lets you move indexing to the background or disable it, so the import doesn’t slow the server down. If you disable it completely, schedule a full indexing run afterwards. If you move it to the background, the message queue has to work through the indexing before the shop shows the new data.
6. Set up delta sync and error handling. In live operation, only changes are transferred. Failed records are logged and retried — and someone is responsible for reading the log.
7. Sign off with metrics. Before go-live, check both by sampling and automatically: are all mandatory fields filled per channel? Are variants, images and translations correct? Do delta changes arrive in the shop within the agreed time window?

Checklist: are you ready for the integration?

• ☐ The leading system is documented in writing for every type of data.
• ☐ The item number is unique, stable and identical in PIM, ERP and shop.
• ☐ Mandatory fields are defined per channel and per language.
• ☐ The split into properties, options and custom fields has been decided.
• ☐ Value lists for filterable attributes are maintained, not set up as free text.
• ☐ Images have a fixed order and a defined cover image.
• ☐ There is a mapping specification with transformation and empty-value rules.
• ☐ Error log, retry logic and a responsible person have been named.
• ☐ The initial load has been tested with a trial run on a staging environment.

If you’re missing more than three ticks, the work lies in the data model first, not in the interface. Which requirements depend on your role in the supply chain is covered in PIM system: manufacturer vs. retailer; if you haven’t chosen a system yet, the PIM software comparison will help.

What the apollon Shopware agency takes care of

Many integration projects have a structural problem: the PIM vendor and the shop agency are two service providers with two timelines and an interface in between that, when in doubt, nobody feels responsible for.

apollon is both: a PIM vendor with Online Media Net (OMN) and an official Shopware partner. That’s why product data platform, integration and shop come from a single source with us:

• Our own middleware between OMN and Shopware 6. It synchronises product data, categories, media and prices.
• Delta exports. Only changed data is transferred.
• Configurable field mapping between OMN and Shopware, plus support for custom fields and sales channels.
• Error logging and automatic retries, so nothing gets stuck unnoticed.
• Shop development, migration and ERP integration from the same team, so the PIM integration is planned in from day one.

What this looks like in customer projects:

• Compass and SEALAND24: Relaunch of the online shops on Shopware 6 with a new design; product information comes from OMN, and the shops are connected to PIM and ERP (success story).
• Egle: The existing Shopware shop is supplied from OMN with product information, digital assets and current prices; we continue to develop the shop and integrate ERP and OMN (success story).
• Boerlind: Product data from OMN flows automatically into the B2C online shop via a direct integration with Shopware 6 (success story).
• Hellmut Ruck: The B2C shop for the own brand peclavus runs on Shopware 6 and draws its product data from OMN (success story).
• Pewag: International configurator on Shopware 6 with OMN integration.

Already running an ERP? Then we connect Shopware to it via our middleware as well.

FAQ: Shopware 6 and PIM

Does Shopware 6 need a PIM?

Not necessarily. For a single shop with one language and a manageable range, Shopware’s built-in tools are often enough. A PIM pays off as soon as the same product data flows into several channels, multiple languages are maintained, supplier data needs standardising or several teams work on the data with approvals.

How is product data transferred from a PIM to Shopware 6?

Via an integration layer that writes to Shopware’s Admin API. For larger data volumes, the Sync API bundles many write operations into one request. The integration layer can be a ready-made connector from the Shopware Store, a middleware or a custom integration. In live operation, only changes (delta) are transferred.

Which mandatory fields does a product need in Shopware 6?

When creating a product via the Admin API, five fields are mandatory: name (name), product number (productNumber), tax rate (taxId), price (price) and stock (stock). Variants additionally need the reference to the parent product (parentId), their own product number, a stock value and their options.

What is the difference between properties and custom fields in Shopware 6?

Properties are structured attributes with fixed values that lend themselves to filtering and comparison. Variant-defining attributes such as colour or size are used as options. Custom fields (customFields) store any other data such as text, numbers, dates or media, but they don’t appear in the storefront automatically. Rule of thumb: select = option, filter = property, read only = custom field.

Is Shopware’s CSV import enough for a PIM integration?

For occasional bulk changes, yes; as a permanent integration, hardly. The profile-based import is file-based, is triggered in the admin or via the command line (import:entity command) and, according to the Shopware documentation, can only add information, not remove it — it cannot remove a sales channel assignment, for example. An automated integration via the Admin API transfers changes continuously and handles errors systematically.

Should prices and stock come from the PIM or from the ERP?

Often the ERP leads for prices, tiered prices and stock, because these values change quickly and originate there commercially. The PIM leads for copy, attributes, media and translations. What matters is that exactly one system leads for each type of data — and that this is decided before the project starts.

Connector plugin or middleware: which is better?

It depends on your starting point. A ready-made connector from the Shopware Store is quick to get going if the data model is close to the standard and Shopware is the only target channel. Middleware pays off if the connector hits limits with custom fields, special logic or multiple target systems, or when mapping, delta detection and error handling are to be controlled centrally.