Shopware Integrations: ERP, PIM, and OMS Patterns That Work

The integration architect had worked on Magento projects for years. He knew how to connect NetSuite, how to sync inventory from the WMS, how to handle pricing conflicts between systems. When his company chose Shopware for a new B2B build, he assumed integration would work the same way.

It didn’t. His first instinct was to build direct database connections and scheduled sync jobs. The same patterns that worked on Magento. Three weeks into development, he had data inconsistencies, missed order events, and sync conflicts that took hours to debug. The patterns that made him successful on Magento were creating problems on Shopware.

The issue wasn’t that Shopware was harder to integrate. It was architecturally different. Shopware’s API-first, event-driven design rewards different patterns than Magento’s hook-and-override approach. Once he understood the difference, integrations became cleaner than anything he’d built on Magento.

This is the guide we wish existed when we started building Shopware integrations. Not feature documentation. Integration patterns that actually work in production.

---

Key Takeaways

Shopware ERP integration follows different patterns than Magento. If you apply Magento patterns to Shopware, you’ll create the same maintenance problems you left Magento to escape.

Integration Principle	Magento Approach	Shopware Approach
Data sync	Scheduled jobs, direct queries	Event-driven, message queue
Extending functionality	Override core classes	Subscribe to events, add custom entities
API usage	REST/GraphQL available but not primary	API-first (everything accessible via API)
Pricing from ERP	Custom module overriding price model	Price calculation subscriber + API calls
Inventory sync	Database sync or MSI	Stock updated via API or event subscription

The trap question to ask any Shopware agency: “Walk me through how you handle ERP pricing when the ERP is slow or unavailable.” If they describe direct synchronous calls without caching or fallback, they’ll build an integration that breaks when your ERP has a bad day.

---

Shopware’s Integration Philosophy

Before diving into patterns, understand how Shopware thinks about integrations.

API-First Means API-First

In Magento, the API is one way to interact with the platform. In Shopware, the API is the primary interface. The admin panel uses the same API your integrations use. This isn’t just architecture philosophy. It means:

• Every capability is API-accessible
• API documentation stays current (it has to, the admin depends on it)
• Custom integrations have the same access as native features

Event-Driven Architecture

Shopware uses an event system (built on Symfony’s event dispatcher) that fires events for virtually every platform action. Order placed. Customer created. Price calculated. Stock changed.

Good Shopware integrations subscribe to these events rather than polling for changes. This is fundamentally different from Magento’s cron-based sync patterns.

Sync Approach	How It Works	Best For
Polling/Cron	Check for changes on schedule	Legacy systems that can’t push
Event subscription	React to changes as they happen	Real-time sync, modern systems
Webhook	Platform pushes changes to endpoint	External systems, microservices

Shopware supports all three, but event subscription is the native pattern that works best.

Message Queue for Heavy Lifting

For integrations that involve heavy processing (large data syncs, complex calculations, external API calls), Shopware’s message queue handles async processing. This keeps the platform responsive while integrations run in the background.

---

ERP Integration Patterns

ERP integration is where B2B platforms succeed or fail. Here’s how to approach it in Shopware, based on patterns we’ve validated with NetSuite, SAP Business One, Microsoft Dynamics, and Sage integrations.

Pattern 1: ERP as Pricing Authority

The most common B2B pattern: prices live in the ERP, and the platform displays them.

Wrong approach: Override Shopware’s price calculation, query ERP directly during cart/checkout.

This creates performance problems (ERP calls on every page load) and tight coupling (ERP downtime breaks the site).

Right approach: Use Shopware’s price calculation events with caching and fallback.

1. Subscribe to ProductPriceCalculatedEvent
2. Check cache for customer-specific price
3. If cache miss, queue async ERP lookup
4. Return cached/fallback price immediately
5. Update cache when async lookup completes

This pattern keeps checkout fast while maintaining ERP as source of truth. The cache layer handles the gap between “real-time” expectations and practical performance.

ERP Pricing Pattern	Latency	Accuracy	Complexity
Direct API call on every request	High	Real-time	Low
Scheduled full sync	Low	Stale (minutes to hours)	Medium
Event-driven with cache	Low	Near real-time	Medium
Hybrid (cache + async refresh)	Low	Near real-time	Higher

For most B2B operations, the hybrid pattern with 15-minute cache TTL provides the right balance.

We implemented this pattern for a distributor with 8,000 customer-specific price lists in SAP Business One. During peak load, the cache handles 95% of price requests without touching SAP. The 5% that require fresh lookups complete async, and customers see prices within seconds of login. Before this pattern, their checkout would timeout whenever SAP was under load.

Pattern 2: Order Flow to ERP

Orders need to reach your ERP. Shopware’s approach:

Subscribe to OrderPlacedEvent, not a cron job that polls for new orders.

1. OrderPlacedEvent fires
2. Subscriber validates order data
3. If valid, queue message for ERP transmission
4. Message handler transforms to ERP format
5. Handler sends to ERP via API
6. On success, update order custom fields with ERP order number
7. On failure, queue for retry with exponential backoff

The message queue is critical. ERP APIs fail. Networks timeout. A direct synchronous call during checkout creates customer-facing errors. The queue pattern handles failures gracefully.

Pattern 3: Inventory Sync from ERP

Inventory should flow from ERP/WMS to Shopware, not the reverse.

Best pattern: Webhook or scheduled push from ERP to Shopware API.

1. ERP/WMS detects inventory change
2. System calls Shopware Stock API with new quantities
3. Shopware updates stock and fires StockUpdatedEvent
4. Any dependent logic (low stock alerts, etc.) triggers automatically

If your ERP can’t push, use a lightweight middleware service that polls the ERP and pushes to Shopware. Don’t build polling logic into Shopware itself.

What this really means: Shopware should receive inventory data, not fetch it. This keeps the integration layer outside the platform where it’s easier to maintain and debug.

---

PIM Integration Patterns

Product Information Management systems are the source of truth for product data. Here’s how to connect Akeneo, Salsify, inRiver, or Pimcore to Shopware.

Pattern 1: Full Product Sync

For initial loads and major catalog updates.

Sync Stage	Approach
Products	Shopware Sync API (bulk operations)
Categories	Sync API with hierarchy awareness
Media	Import API with URL references
Properties/Attributes	Map to Shopware custom fields
Associations	Handle after base entities exist

Shopware’s Sync API is designed for bulk operations. It handles 10,000+ products efficiently if you batch correctly (500-1000 per request is optimal).

Pattern 2: Incremental Updates

For ongoing sync after initial load.

Subscribe to PIM change events (if your PIM supports webhooks) or use a scheduled delta sync:

1. Query PIM for changes since last sync timestamp
2. Transform to Shopware entity format
3. Use Sync API with upsert behavior
4. Update sync timestamp on success

Avoid per-product API calls. The Sync API handles bulk upserts much more efficiently than individual product updates.

Pattern 3: Handling Attributes and Properties

Shopware’s property system is flexible but different from Magento’s EAV model.

Data Type	Shopware Approach
Filterable attributes	Properties (with property groups)
Non-filterable data	Custom fields on product
Variant attributes	Options (color, size, etc.)
Specifications	Custom fields or properties depending on use

Map your PIM attributes to the right Shopware construct during integration planning. Changing this later requires data migration.

---

OMS Integration Patterns

Order Management System integration handles the post-purchase flow: fulfillment, shipping, returns. Whether you’re connecting ShipStation, Shippo, a 3PL’s custom system, or an OMS built into your ERP, these patterns apply.

Pattern 1: Order Export to OMS

Same pattern as ERP order flow:

1. Subscribe to OrderPlacedEvent
2. Transform order to OMS format
3. Queue for transmission
4. Handle success/failure appropriately

If your OMS is your ERP (common with NetSuite or SAP), this might be a single integration. If they’re separate systems, you’ll have parallel flows. The key is using the message queue so OMS failures don’t block checkout.

Pattern 2: Fulfillment Updates from OMS

When orders ship, Shopware needs to know.

Webhook from OMS to Shopware:

1. OMS marks order shipped
2. OMS calls Shopware API with tracking info
3. Shopware updates order state
4. OrderStateChangedEvent fires
5. Customer notification triggers automatically

Use Shopware’s state machine for order status. Don’t create custom status fields. The state machine integrates with notifications, workflows, and reporting.

Pattern 3: Returns and RMA

Returns are complex. Shopware’s Flow Builder and state machine provide structure without custom code.

1. Return request created (via API or admin)
2. Return entity linked to original order
3. State machine manages return workflow
4. Inventory updates on return completion
5. Refund triggers if applicable

Build return logic using Shopware’s Flow Builder where possible. Flow Builder lets operations teams modify workflows without developer involvement. Custom code for returns becomes maintenance burden and removes that flexibility.

---

At this point, you understand Shopware’s integration philosophy. The remaining question is how to structure your specific integration architecture.

---

Integration Architecture Decisions

Before building, answer these questions:

Where Does the Integration Layer Live?

Option	Best For	Trade-offs
Custom Shopware plugin	Simple integrations, Shopware-specific logic	Ties integration to platform upgrades
External middleware	Complex orchestration, multiple targets	Additional infrastructure to maintain
iPaaS (Celigo, Workato, etc.)	Standard connectors exist, limited dev resources	Licensing cost, less flexibility

The decision rule: If you have more than three external systems connecting to Shopware (ERP + PIM + OMS, or ERP + WMS + 3PL + payment gateway), move integration logic to external middleware. If you have one or two systems with straightforward sync requirements, a Shopware plugin is acceptable. The threshold isn’t arbitrary. Three systems means you’re orchestrating data flows, handling conflicts between systems, and debugging across multiple APIs. That complexity doesn’t belong inside your ecommerce platform.

For complex B2B with multiple systems, external middleware isolates integration complexity from platform maintenance. Your Shopware upgrades become simpler because your integration layer is decoupled.

Sync Direction and Frequency

Data Type	Direction	Typical Frequency
Products	PIM → Shopware	Event-driven or hourly
Prices	ERP → Shopware	Near real-time (cached)
Inventory	WMS/ERP → Shopware	Real-time or every 5-15 minutes
Customers	Bidirectional	Event-driven
Orders	Shopware → ERP/OMS	Real-time (event-driven)
Shipments	OMS → Shopware	Event-driven

Error Handling and Monitoring

Every integration needs:

• Dead letter queue for failed messages
• Alerting when failures exceed threshold
• Manual retry capability for stuck transactions
• Audit log showing what synced when

Shopware’s admin doesn’t provide this visibility natively. Build it into your middleware layer or use external monitoring.

Rate Limiting and ERP Protection

B2B ERPs are not built for ecommerce traffic patterns. A flash sale, a bulk reorder, or even a busy Monday morning can generate hundreds of API calls per minute. Most ERPs will choke, timeout, or crash.

Shopware’s message queue acts as a traffic warden between your storefront and your ERP.

Without Message Queue	With Message Queue
200 orders = 200 simultaneous ERP calls	200 orders = 200 queued messages
ERP overloads, timeouts, lost orders	Messages processed at controlled rate
Customer-facing errors during peak load	Checkout stays fast, ERP catches up
No retry on failure	Automatic retry with exponential backoff

The pattern: Configure your message queue consumers to process ERP-bound messages at a rate your ERP can handle. If your ERP can process 10 orders per minute reliably, set your consumer to that rate. The queue absorbs spikes. The ERP never sees more than it can handle.

This is especially critical for real-time pricing lookups. Without rate limiting, a product listing page with 50 items could fire 50 simultaneous price requests to SAP. With proper queue configuration, those requests are batched or throttled to stay within SAP’s comfort zone.

---

Common Integration Mistakes

We’ve debugged enough failed Shopware integrations to recognize patterns. Here’s what goes wrong.

Mistake	What Happens	How to Avoid
Direct database writes	Data inconsistencies, missed events, broken by upgrades	Always use APIs or entity repositories
Synchronous ERP calls in checkout	Timeouts, customer-facing errors when ERP is slow	Queue everything, use cache with fallback
Polling Shopware for changes	Missed events, high database load, stale data	Subscribe to events, let Shopware push
Ignoring the message queue	Failed syncs with no retry, lost orders	Queue all external calls, build retry logic
Custom status fields instead of state machine	Broken notifications, reporting gaps, Flow Builder incompatibility	Use native state machine, extend if needed

The underlying principle: Shopware’s architecture has opinions. Fighting those opinions creates maintenance burden. Working with them produces cleaner integrations.

---

The Decision

Shopware’s integration architecture is cleaner than Magento’s. But “cleaner” only matters if you use it correctly.

The patterns that worked on Magento (direct database access, cron-based polling, core class overrides) create problems on Shopware. The patterns that work on Shopware (event subscription, message queues, API-first) produce integrations that are easier to maintain and debug.

The one thing to remember: Shopware should react to events and receive data via API. It should not poll external systems or make synchronous calls during user-facing operations. If your integration architecture follows this principle, most of the patterns in this guide will feel natural. If it doesn’t, you’ll fight the platform until you refactor.

If you’re coming from Magento, unlearn the old patterns. If you’re new to both platforms, Shopware’s approach is more aligned with modern integration best practices.

The API-first architecture isn’t marketing. It’s how the platform actually works. Build with it, not against it.

---

Planning Shopware integrations for ERP, PIM, or OMS? Before you build, we can review your integration architecture against patterns that have worked (and failed) in production. Bring your system diagram and ERP documentation. We’ll identify the two or three decisions that will determine whether your integration is maintainable or becomes a constant firefight. That’s usually a 30-minute call.

Shopware Integration: Strategic FAQ

Planning a complex Shopware integration for ERP, PIM, or OMS? Don’t settle for fragile sync jobs. Let’s spend 20 minutes reviewing your system diagram and ERP documentation to identify the specific patterns that will ensure your architecture remains performant and maintainable for the long haul.