Shopware lists Nexus as generally available. The developer documentation, however, still describes the feature set as beta, without an SLA and without 24/7 support. Anyone checking whether Nexus can replace their existing middleware or a self-built interface will also run into two points that no announcement puts front and centre: Nexus does not accept inbound webhooks, and it does not run custom code.
This article reflects the state as of 21 October 2026. Where the product page, roadmap and documentation differ, we follow the documentation and flag what has only been announced. Shopware Payments and the Experience Studio, which Shopware presented alongside Nexus, are out of scope; our article on Shopware Community Day 2026 gives the overview.
What Shopware Nexus is
Nexus is an integration platform in the sense of an iPaaS (Integration Platform as a Service). It does not run inside the shop but as a separate service at nexus.shopware.com. The shop reports events via the Shopware Nexus Event Ingestion Service, a workflow starts there and calls the target systems. Processing is based on Apache Kafka. Failed runs are retried automatically and, if that fails too, end up in a dead-letter queue.
The difference from external middleware is access. A tool like n8n or a classic iPaaS solution sees Shopware from the outside, through the Admin API and webhooks. Nexus is developed by Shopware itself and accesses the shop's events and data structures without requiring a plugin. Shopware also promises that workflows and connectors stay compatible across Shopware updates. That matters because self-built interfaces regularly need rework at major versions, for example when events or entity definitions change.
Setup requires Shopware 6.7.1.0 or newer, a Shopware account linked to a company and admin access to the shop. Shops still on 6.5, 6.6 or 6.7.0 have to update first; our Shopware 6 update roadmap describes the order.
Nexus, Flow Builder, plugin or middleware: who does what
With the Flow Builder, Shopware already has an automation tool. It controls processes inside the shop, such as a status change or an email after an order. From the Evolve plan onwards it can also send data to third-party systems via a webhook action, but without ready-made connectors to ERP, PIM or CRM. Nexus orchestrates processes across system boundaries. Plugins and apps remain the way to extend Shopware itself.
| Tool | Scope | Typical use | Operation |
|---|---|---|---|
| Flow Builder | inside Shopware, webhook actions from Evolve | email, tag, status change after an event | in the shop, included in the plan |
| Shopware Nexus | Shopware ↔︎ external systems | order to ERP, stock sync, notifications | Shopware service in the EU, billed per execution |
| Plugin / app | extends Shopware itself | custom logic, fields, checkout changes | in the shop, maintenance on updates |
| External middleware (e.g. n8n, iPaaS) | any systems with each other | multi-system processes, custom code, inbound webhooks | own or third-party server, own maintenance |
The tools overlap when data is exchanged between the shop and a third-party system. Whether Nexus can replace the existing solution there depends on the connectors and on the direction of the data flows.
How a Nexus workflow is built
A workflow consists of nodes that are connected on a canvas by drag and drop and organised in projects. It is triggered either by a Shopware event, for example a new order (order.placed), or by a cron-style schedule, such as hourly or nightly.
Actions follow: a Shopware API call, any external API request, a Business Central operation, a Slack message, a Shopware email or storage in S3. There are also conditions (if/else, switch), a delay node and a data transformation for mapping and filtering fields. Placeholders in double curly braces insert event data into messages and requests. That is enough to map orders to ERP sales orders. Tiered pricing or tax calculations are not covered by the documentation; that kind of logic does not belong in Nexus for now.
For agencies and merchants with several shops, one detail is particularly useful: workflows can be exported and imported into another environment, and only integration IDs are transferred instead of credentials. The API keys therefore stay in the respective tenant, stored in encrypted form according to the documentation. Node configurations such as field mappings can be saved as templates and reused.
For multiple companies, the sources contradict each other: the announcement article and the user documentation describe an organisation switcher for separate tenants, while the getting started page of the developer documentation lists as an Early Access limitation that only the first linked company is used. If you plan several organisations, clarify this in the portal beforehand.
According to Shopware's update of 6 October, Copilot is integrated into Nexus to create, improve and debug workflows in natural language. The public roadmap, however, still lists AI-generated workflows, AI debugging and automatic data mappings as "coming soon". In practice, the status changes little. Copilot builds a workflow faster. Whether VAT, shipping costs and discounts arrive correctly in the ERP is something it does not check.
Which systems Nexus connects today
The developer documentation describes the following available building blocks: Microsoft Dynamics 365 Business Central (read, create, update and delete for items, customers and sales orders), Slack, S3 and S3-compatible storage, the Shopware API and a generic API request for any external system with an HTTP interface.
The product page also names connectors for Odoo, NetSuite, ERPNext, Pimcore, Akeneo, Mailchimp, Klaviyo, Brevo and others. On the Shopware roadmap the same names appear under "Nexus: Upcoming Connectors" with the status "in progress", 41 entries in total, including HubSpot, Zoho CRM and Google Sheets. The October update added configuration-based connectors that are meant to enable custom integrations with less custom code. The developer documentation lists SAP and Oracle only under "Post-GA".
The reliable working basis for a Shopware ERP integration is therefore: Business Central is documented as a ready-made connector. Any other system with an accessible REST API can be connected via the generic API request, then with your own mapping and your own error handling. Whether a native connector for your ERP system or your PIM is enabled at project start is something you check in the Nexus portal, not on the product page.
The most important limit: the direction of the data
Shopware justifies both limits from the introduction with security concerns: there are currently no inbound webhooks and no custom code. Nexus can therefore react to shop events and actively fetch data. An ERP, a logistics provider or a marketplace, however, cannot report a change to Nexus on its own.
For stock levels, this is the crux. If stock changes in the ERP, the change only reaches the shop through Nexus via a scheduled fetch. With an hourly sync, an item can remain on sale with incorrect stock for up to an hour. With 50 items and large stock that does not matter; with clearance goods and tight stock it does. A shorter interval solves the latency problem but costs executions, as the next section shows.
Logic that cannot be modelled with the available nodes still needs another home: a plugin in the shop, an app or middleware.
What Shopware Nexus costs
Billing is per execution, and according to the Nexus pricing page an execution is one successfully executed node, not a complete workflow run. Each shop receives a monthly allowance depending on its Shopware plan, which expires at the end of the month and does not carry over. Beyond that, 1,000 executions cost 10 euros net. The pricing page has shown this model since October 2026; before that it listed a free introductory phase. Shopware does not explicitly state from which date billing actually applies.
| Shopware plan | Plan price (net, list) | Included executions per month |
|---|---|---|
| Community Edition | free | 100 |
| Rise | from €600 / month | 1,000 |
| Evolve | from €2,400 / month | 2,000 |
| Beyond | on request | 5,000 |
Because every node counts, you calculate from the workflow design. A model calculation for a shop on the Rise plan with 1,500 orders a month, assuming every node including the trigger counts and partial blocks are charged in full:
- Order workflow with four nodes: 4 × 1,500 = 6,000 executions.
- Hourly stock sync with three nodes: 24 × 30 × 3 = 2,160 executions.
Together that makes 8,160 executions. Minus the 1,000 included, 7,160 remain, i.e. eight blocks of 1,000 or 80 euros a month.
If the stock sync runs every 15 minutes because stock is tight, this becomes 4 × 24 × 30 × 3 = 8,640 executions for that workflow alone. Together with the orders that is 14,640 executions, so 140 instead of 80 euros a month on the Rise plan. That is the price of the missing inbound webhooks: an ERP that could report changes would not need a fetch every quarter of an hour.
The public documentation does not say how nodes count when they process many records. If every record counted individually, an hourly sync of 5,000 items with one processing node would add up to 720 × 5,000 = 3.6 million executions a month.
That is a hypothesis. It shows, however, why the counting method is the first thing to check in the pilot and why a sync should only transfer changed stock (delta sync). The workflow metrics in the Nexus portal show the messages processed per node; compare them with the first invoice before you extrapolate.
In the model calculation, execution fees with a delta sync range between 80 and 140 euros a month. Build, mapping, testing and maintaining the workflows cost more. That is exactly where Shopware positions Nexus, citing up to 40 percent lower integration costs. According to the footnote, the figure comes from internal project analyses and beta assumptions; there is no independent measurement.
Maturity: what "generally available" means today
Shopware announced Nexus on 28 May 2026 in an article titled "enters general availability", whose body text refers to Early Access. The presentation at Community Day followed on 10 June, and on 6 October an update that speaks of the "general release".
The developer documentation, by contrast, lists for the current phase no SLA guarantees, no 24/7 support, operation in the EU only without self-hosting or on-premise, and no workflow marketplace yet.
The getting started page lists further Early Access limitations, two of which matter for planning: there is no test mode, so testing happens with staging shops. And messages are delivered at least once ("at-least-once"), so workflows should be built to be idempotent. For an order handover, this means the ERP must not create the same sales order twice on duplicate delivery, for example because the workflow first checks whether the order number already exists.
That Nexus is operated in the EU simplifies the data protection assessment for the service itself. Where data flows after that is determined by the connected target systems. The missing SLA, on the other hand, is a real criterion, because the order handover to the ERP is business-critical. Retries and the dead-letter queue catch errors in the target systems; for an outage of Nexus itself there is no commitment without an SLA. By its own account, Shopware currently aims Nexus mainly at developers and technical teams, with usability for merchants and operations teams to follow.
The developer documentation already describes role-based access control with the roles Admin, Builder and Viewer. Further operational features have so far only been named in the announcement article. A rate-limiting node is in progress. A circuit breaker that throttles requests when a target system returns frequent server errors is being explored, and a monitoring export, for example to Grafana, is planned.
When Nexus replaces middleware and when it does not
The distinction becomes clearest when you go through the typical data flows of the model shop (Rise, 1,500 orders, hourly sync):
- Order → Business Central: fits. The flow starts in the shop, the connector is documented, and the logic consists of mapping and one condition.
- Stock ERP → shop: fits with limitations. Only on a schedule, i.e. with a delay and execution costs per interval.
- Shipping status from the logistics provider via webhook → shop: currently does not fit. The third-party system would have to report actively; that remains a job for middleware or a plugin.
Middleware or a custom build also remains the better solution when SAP is connected; there is no native connector for it. The same applies when processes need custom code or an SLA for the interface is contractually required. For processes that connect several systems without a shop reference, such as CRM, accounting and ticketing, a general-purpose tool like n8n is the better fit, because Nexus is designed around Shopware as its centre.
Our recommendation: build new, shop-related integrations in Nexus and only migrate existing, stable Shopware interfaces when a rework is due anyway.
How to evaluate Nexus for your shop
A five-step assessment prevents the decision from getting stuck on the connector list or the price:
- Create an integration inventory: list all data flows between the shop and third-party systems with direction, frequency, data volume and criticality.
- Check the direction: mark every flow that needs inbound webhooks or custom code. These flows stay outside Nexus for now.
- Compare connectors: check in the Nexus portal which systems are available natively and which would have to run via the generic API request.
- Estimate executions: nodes per workflow times triggers per month, against your plan's allowance.
- Pilot on a staging shop: activate the Event Ingestion Service under Settings → Shopware Services, link the shop under Settings → Nexus and set up a non-critical workflow, such as a Slack message for orders above a threshold.
In the pilot, deliberately trigger an error in the target system and check whether the run shows as failed and can be retried. You simulate a duplicate delivery by processing the same event twice; the target system may only create the record once. In parallel, keep count of the messages processed per node.
Only once the pilot runs stably does a business-critical flow such as the order handover to the ERP belong in Nexus.
Frequently asked questions about Shopware Nexus
Which Shopware version do I need for Nexus?
At least 6.7.1.0. Shops on 6.7.0, 6.6 or older have to update first.
Does the trigger count as an execution?
The public documentation does not specify this. The model calculation above counts it to be on the safe side; the first invoice from the pilot will provide clarity.
Does Nexus replace the Flow Builder?
No. The Flow Builder remains responsible for automations inside the shop. Nexus comes in when data needs to be mapped, retried or distributed to several external systems.
Can I host Nexus myself?
No. Nexus runs as a Shopware service in the EU; self-hosting is not planned.
Conclusion: who Shopware Nexus is worth it for today
Nexus closes the gap between shop and third-party system with direct access to shop events, operation in the EU, retry logic and fees that stay manageable with clean workflow design. For new integrations that start in the shop or fetch on a schedule, Nexus is a serious option today. For inbound real-time data, SAP landscapes and processes with custom logic, it is not yet.
So start with the pilot from step 5 before you plan a migration. If you want support with that or with reviewing your existing interfaces, we can help as your Shopware agency, from inventory through pilot to implementation.