Shopware Nexus or custom middleware? A decision guide for ERP integrations

Since Nexus went into Early Access, the same question comes up in every other project call: do we still need the custom ERP integration at all?

The answer hangs on two things: how an integration is cut, and who runs it.

What Nexus is

Shopware describes Nexus as a native iPaaS built into the platform. In practice it is a cloud service with a visual workflow editor, reachable at nexus.shopware.com and connected to the shop through the Nexus Event-Ingestion Service.

A workflow consists of a trigger, a chain of steps, and outbound actions. The documentation lists two trigger types: Shopware events like order.placed and scheduled runs in cron style. In between sit conditional branches and data transformations.

The documentation lists five action nodes: the Business Central connector, Shopware API calls, Slack notifications, Shopware email, and generic API requests. On top of that there is an output node that writes data to S3-compatible object storage. The product page lists further connectors as under review, among them Pimcore, NetSuite, and Akeneo.

What is new here, and what is not

Event-driven workflows with a visual editor and connectors have been around for over a decade. Zapier, Make, Workato, Talend, Apache Camel, Node-RED, n8n. The pattern is established, and Nexus follows it.

The value of such a tool is not in the editor but in the connectors. A finished connector takes care of authentication for a specific target system, pagination, rate limit behavior, mapping onto its entities, and the question of what an error message from that system actually means. That part eats the days in a custom build, not the transport.

So the usefulness hangs on a single question: is your target system in the catalog?

In Early Access, the catalog is still small. Of the documented nodes, exactly one writes to a business system: the Business Central connector. Slack message and Shopware email are notifications, the rest is generic transport: HTTP request, calls against your own Shopware API, storage in S3. Under review are Pimcore, NetSuite, and Akeneo, exactly the candidates that would make the difference.

For every other system, the generic API request remains. Then you write mapping, authentication, and error handling yourself again, just in someone else's service instead of your own code.

Whether Nexus saves you work is decided by the connector catalog. If your ERP is not in it, what remains is a workflow editor with an HTTP call.

The event connectivity is also easy to overrate. Nexus delivers Shopware events with no work on your side, but so does a plugin with an EventSubscriber, and that is a few dozen lines. If the receiver runs outside the shop, the app system with <webhooks> in the manifest does the job. The native trigger is convenient, but it is not a unique selling point.

Shopware advertises two numbers: integration costs are supposed to drop by up to 40 percent, and 52 percent of project effort is said to be lost to custom middleware on average. Both numbers carry a footnote mark on the product page, with no derivation behind it. Without a baseline, it stays open what counts as project effort and what the savings were measured against.

Where the effort sits is not in dispute: between the systems, not in the shop. A matching connector covers the standard part of that. In our experience the bigger part is in the special cases, and those still need a solution of your own.

One more distinction, because Nexus and the Flow Builder get mixed up regularly. The Flow Builder automates logic inside the shop, such as status changes or sending mail. Nexus connects the shop to systems outside. The two exist side by side.

Granularity decides the costs

The technical documentation does not name prices, the pricing page does. Shopware lists Nexus there as an add-on: a free introductory phase until September 1, 2026, after that around €10 per 1,000 executions, shown as guide pricing during the beta.

Billing is per execution, and exactly that changes how you cut an integration.

As an example, a shop with 5,000 products and 200 orders per day, connected to an ERP.

Order flow, event-driven:

Each order triggers four executions. Order to the ERP, customer sync, status feedback, tracking number back to the shop.

200 orders × 4 steps × 30 days = 24,000 executions/month
24,000 / 1,000 × €10 = €240/month

That is unremarkable and cheap for what it delivers.

Inventory sync, one execution per product:

5,000 products × 24 runs/day × 30 days = 3,600,000 executions/month
3,600,000 / 1,000 × €10 = €36,000/month

The same inventory sync as a batch, one execution per run:

24 runs/day × 30 days = 720 executions/month
720 / 1,000 × €10 = €7.20/month

Same function, same amount of data, but a price difference of factor 5,000. The factor stays the same whatever price per execution you plug in.

With your own middleware, granularity is a question of runtime and readability. With Nexus, it is the cost question. Trigger per record instead of per run and you pay a thousand times more.

This is not an argument against Nexus. It is an argument for cutting workflows batch-oriented from the start, wherever real time is not required. Orders should be processed one by one, inventory and prices in bulk.

Where Nexus holds up

In plenty of projects, custom middleware is oversized.

• Standard flows between Shopware and a system that has a connector
• Field mappings without special logic, where an order stays an order
• Manageable volumes where per-execution costs do not matter much
• Notifications to Slack or by mail, where no business logic is needed anyway
• Projects without their own ops team, where every additional component is a risk

In these cases, custom middleware is a cost driver with no return. If you need a Business Central connection with standard fields, take Nexus.

Where the limits are

Part of the following comes down to Early Access and should resolve itself over time. For a decision today, the current state is what counts.

At-least-once delivery. Shopware documents this as a known limitation. An event can arrive more than once. Without idempotency on the receiving side, that can turn into double bookings in the ERP.

No test mode, no undo, limited error details. This is also stated in the documentation. Whoever changes a workflow changes it in production. As a way out, the docs recommend staging shops, meaning a second environment you maintain yourself. And for debugging there are fewer details available than you are used to from your own middleware.

Error handling with checkpoints. What happens when the ERP stops responding in the middle of a batch of 3,000 products? Custom middleware has state, resumes from the last confirmed record, and reports the abort to monitoring. The Nexus documentation does not mention such a feature.

Custom data models. As soon as product data is spread across several entities, configurators are involved, or prices are calculated by customer group, tier, and campaign logic, field mappings are no longer enough.

Systems without a connector. SAP, Oracle, Salesforce, and practically every ERP in the German Mittelstand run through the generic API request. The effort for mapping and error handling stays with the project. The advantage over any other workflow tool then shrinks to the event trigger.

Operation outside the cloud. The documentation describes Nexus as a cloud service. A self-hosted variant is not documented. If you need control over the runtime environment for regulatory reasons or because downtime is expensive, you will not find it here.

The three-year comparison

The following calculation uses the per-execution price named by Shopware and a middle scenario: a connection to a system with an existing connector, standard fields, 24,000 executions per month. The day rate (€1,000) and the person-days are assumptions from our project work. If you have your own numbers, plug them in, the structure of the calculation stays the same.

For this scenario, Nexus is about four times cheaper. If you build your own anyway, you should be able to name good reasons.

At high volumes the calculation flips, because usage costs grow linearly while the costs of your own middleware stay largely fixed. It flips with special logic, because the initial effort on the Nexus side no longer sits at 6 person-days. And it flips for systems without a connector, because both sides then build the same mapping, except one of them also bills per execution.

One item is missing from the table because it is hard to put a number on.

Lock-in on critical processes

The calculation above rates effort, but not how hard the decision is to walk back later. For a Slack notification that plays no role, for the order flow it does.

The dependency has four levels:

The last row weighs heaviest in practice.

Custom middleware is exactly the part that makes replatforming affordable. It knows the ERP, the mappings, and the special cases from years in production. When the shop system changes, you swap the shop adapter and keep the rest.

Map the ERP integration entirely in Nexus and a shop switch becomes an integration project on top. In practice, exactly this calculation often decides whether a replatforming happens at all.

What being tied to the account means in practice

Usage-based prices are plannable as long as the model stays stable. An episode from last year shows what being tied to a Shopware account means in practice.

As of March 24, 2025, Shopware introduced a Fair Usage Policy. Since then, the Community Edition is free to use without restriction up to €1 million GMV per year. Above that, you move to a paid plan. All Community Edition users are required to report their GMV, regardless of size, with the first deadline on June 30, 2025.

What a move means is on the pricing page: Rise starts at €600 per month plus VAT, Evolve at €2,400, Beyond on request.

For planning, the interesting part is less the threshold than where the policy takes hold. The Community Edition code is still MIT-licensed, the policy did not change that. It governs access to the Shopware Account and Store. Anyone above the threshold who does not switch risks a blocked account and store, including cancellation of rented extensions. The shop itself keeps running: according to Shopware, the Community Edition can still be used without account and store.

Nexus requires an active Shopware account and hangs on exactly that level. Unlike the shop, there is no MIT-licensed part here that keeps running without the service.

This is not an accusation. Every vendor is allowed to evolve its model, and there were understandable reasons for this step. For your own planning it just means: the more business process hangs on a service, the less room you have the next time the vendor adjusts.

The same goes for product decisions. OpenAI withdrew Instant Checkout after around five months, and no vendor is immune to such course corrections. For a Slack notification that is survivable, for an order flow less so.

Reducing lock-in without giving up Nexus

The way out is splitting the integration: Nexus takes the trigger and transport, the business logic stays in your own code. The workflow no longer models conditions, mappings, or error handling. It calls your own endpoint and hands over the raw data. Everything from that point on lives in the repository, versioned, testable, and independent of Nexus.

This split only pays off for critical flows. A Slack message for every order above €5,000 belongs entirely in the canvas, meaning the visual workflow editor of Nexus. A dedicated endpoint for that would be overhead.

For the critical flows, a fair question remains: if the business logic lives in your own code anyway, why send the event through Nexus at all? There are two reasons, and at least one should apply:

• The target side has a finished connector. Your endpoint prepares the data and hands it back, the connector does the writing into the target system. That saves you its authentication and error handling while the business logic stays in the repository.
• The same event goes to several receivers, and that list changes. An additional receiver is a configuration change in the workflow, a release in your own code.

If neither applies, Nexus has no job left in that flow. The event then runs through a paid service only to land at an endpoint that does everything itself. A plugin with an EventSubscriber takes it there directly.

The following endpoint shows the receiving side. The idempotency in it is mandatory, not a precaution: Shopware documents at-least-once delivery, so the same event can arrive more than once.

<?php

declare(strict_types=1);

namespace App\Controller;

use App\Message\ProcessOrderMessage;
use Psr\Log\LoggerInterface;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Messenger\MessageBusInterface;
use Symfony\Contracts\Cache\CacheInterface;
use Symfony\Contracts\Cache\ItemInterface;

final class OrderWebhookController
{
    public function __construct(
        private readonly MessageBusInterface $bus,
        private readonly CacheInterface $idempotencyStore,
        private readonly LoggerInterface $logger,
        private readonly string $webhookSecret,
    ) {
    }

    #[Route('/hooks/order-placed', methods: ['POST'])]
    public function __invoke(Request $request): Response
    {
        $payload = $request->getContent();

        // 1. Verify the signature. The endpoint is publicly reachable,
        //    authenticity rests entirely on the HMAC.
        if (!$this->isSignatureValid($payload, (string) $request->headers->get('X-Signature'))) {
            return new JsonResponse(['error' => 'invalid signature'], Response::HTTP_UNAUTHORIZED);
        }

        $data = json_decode($payload, true, 512, JSON_THROW_ON_ERROR);
        $orderNumber = (string) ($data['orderNumber'] ?? '');

        if ($orderNumber === '') {
            return new JsonResponse(['error' => 'orderNumber missing'], Response::HTTP_BAD_REQUEST);
        }

        // 2. Idempotency. With at-least-once delivery the same event
        //    arrives more than once. The protection belongs on your side.
        $isDuplicate = true;
        $this->idempotencyStore->get(
            'order_hook_' . $orderNumber,
            function (ItemInterface $item) use (&$isDuplicate): bool {
                $item->expiresAfter(86400);
                $isDuplicate = false;

                return true;
            }
        );

        if ($isDuplicate) {
            $this->logger->info('Duplicate call discarded', ['orderNumber' => $orderNumber]);

            return new JsonResponse(['status' => 'duplicate'], Response::HTTP_OK);
        }

        // 3. Accept and process asynchronously. The caller gets an immediate
        //    response, the actual work runs in your own worker.
        $this->bus->dispatch(new ProcessOrderMessage($orderNumber, $data));

        return new JsonResponse(['status' => 'accepted'], Response::HTTP_ACCEPTED);
    }

    private function isSignatureValid(string $payload, string $received): bool
    {
        $expected = hash_hmac('sha256', $payload, $this->webhookSecret);

        return $received !== '' && hash_equals($expected, $received);
    }
}

If Nexus goes away, you replace the trigger with an EventSubscriber in your own plugin, a cron job, or a queue consumer. The endpoint, the processing, the error handling, and the mappings stay untouched. The switch costs days, not months.

Three rules cover the day-to-day:

• Every flow gets an answer up front to the question of what happens if it does not run for two days. If the outage is survivable, everything may go into the canvas.
• If the outage gets expensive, the business rules belong in code, not in the canvas.
• If that leaves the workflow with nothing but a single call, the flow does not belong in Nexus but on your own EventSubscriber.

The third option: a self-hosted workflow engine

Workflow engines of this pattern also exist for self-hosting. With n8n, the same kind of workflow runs on your own infrastructure, without per-execution billing.

For Shopware there are community nodes, for example from solution25 and codeblick. Where no node fits, the HTTP node remains. For calls against the Shopware Admin API that is no practical drawback.

The core of the comparison sits in two rows: Nexus delivers the events out of the box and takes over operations, n8n delivers control and traceability. The operational effort is the price: n8n in production means a main instance, workers, Redis, and Postgres, plus backups, updates, and monitoring.

Two things to know about n8n

The license is not OSI-approved. n8n has been under the Sustainable Use License since March 17, 2022, before that Apache 2.0 with Commons Clause. For your own shop this is uncritical: use for internal business purposes is explicitly allowed, and that is exactly what connecting your own systems is. What is off limits is reselling n8n itself as a service.

A second point matters more in practice: files with .ee. in their path are not under the Sustainable Use License but require an enterprise license. This covers features n8n lists as enterprise features, SSO among them. If you need those, you pay with n8n too.

The canvas problem stays. With n8n, too, the logic lives in a graphical editor. The difference is that workflows can be exported as JSON and put into the repository. Properly reviewing those JSON diffs is still barely possible.

n8n takes vendor lock-in and per-execution billing out of the equation. It does not change the underlying problem: business logic in a canvas is harder to check than code.

The recommendation from the previous section stands. Nexus or n8n: trigger and transport belong in the engine, the business logic in your own endpoint.

If you do not need a canvas in the first place, Temporal or a plain combination of Symfony Messenger and cron is often leaner. Kestra, Windmill, and Node-RED go in the same direction as n8n and are worth a look when a specific requirement fits better there.

The hybrid approach

In most mid-sized projects, the decision is not an either-or.

A practical cut:

• A workflow engine takes the standard flows, notifications, and everything event-driven and low-volume. Whether Nexus or n8n depends on whether an ops team exists
• Custom middleware takes the critical flows with state, checkpoints, and special logic, typically product data, prices, and order processing

That shrinks the custom build considerably without the parts that cost money in a failure hanging on a third-party service. The middleware also survives a platform switch.

The price of this path is running and documenting two systems. It pays off from the point where at least one flow hits the limits of Nexus.

Decision matrix

If you agree with the whole Nexus column but have an ops team and want to avoid per-execution billing, you end up with a self-hosted n8n. The technical assessment stays the same, only who runs it changes.

Conclusion

Technically, Nexus is a cloud iPaaS in an established product category. Whether it holds up is decided by the connector catalog: if your target system is in it, it takes real work off your plate. For those cases, custom middleware is off the table. Saying that openly is hard for an agency that lives off exactly these projects. It does not change the fact that it is true.

What remains are the flows with state, special logic, or volume. There, Nexus in its current state is not a replacement but a complement for the simple flows next to them. The reasons come from the documentation itself: no test mode, limited error details, at-least-once delivery. Part of that should resolve itself with upcoming releases.

The cost calculation alone does not carry the decision. For the flows that carry the business, the dependency weighs more than the effort. If you put the ERP integration entirely into a platform that belongs to the shop system, a platform switch means replacing both at once.

Whatever you choose, the same rule applies: business logic in your own repository, trigger and transport in the engine. That keeps the benefit and makes the switch a matter of days.

👉 If you want to know which of your integrations belong in Nexus and which do not:

Sources

• Shopware Docs: Shopware Nexus for requirements, activation, triggers, and actions
• Shopware Developer Docs: Nexus, Getting Started for the known limitations in Early Access
• Shopware Developer Docs: Listening to events for the plugin route via EventSubscriber
• Shopware Developer Docs: App system, webhooks for manifest, registration, and signature verification
• Shopware: Nexus product page for the claims on integration costs and project effort
• Shopware: Pricing for the edition prices and Nexus billing
• Shopware: Fair Usage Policy for the Community Edition for threshold, reporting duty, and deadlines
• n8n: Sustainable Use License and LICENSE.md
• n8n Docs: Queue Mode

Information current as of July 2026. Nexus is in Early Access, scope and terms can change.