Shopware führt Nexus als allgemein verfügbar. Die Entwicklerdokumentation beschreibt den Funktionsumfang dagegen weiterhin als Beta, ohne SLA und ohne 24/7-Support. Wer prüft, ob Nexus die bestehende Middleware oder eine selbst gebaute Schnittstelle ersetzen kann, stößt außerdem auf zwei Punkte, die in keiner Ankündigung prominent stehen: Nexus nimmt keine eingehenden Webhooks an, und es führt keinen eigenen Code aus.
Dieser Beitrag beschreibt den Stand vom 21. Oktober 2026. Wo Produktseite, Roadmap und Dokumentation voneinander abweichen, halten wir uns an die Dokumentation und markieren, was nur angekündigt ist. Nicht Thema sind Shopware Payments und das Experience Studio, die Shopware gemeinsam mit Nexus vorgestellt hat; den Überblick gibt unser Beitrag zum Shopware Community Day 2026.
Was Shopware Nexus ist
Nexus ist eine Integrationsplattform im Sinne eines iPaaS (Integration Platform as a Service). Sie läuft nicht im Shop selbst, sondern als eigener Dienst unter nexus.shopware.com. Der Shop meldet Ereignisse über den Shopware Nexus Event-Ingestion-Service, dort startet ein Workflow und ruft die Zielsysteme auf. Die Verarbeitung basiert auf Apache Kafka. Fehlgeschlagene Läufe werden automatisch wiederholt und landen, wenn auch das scheitert, in einer Dead-Letter-Queue.
Der Unterschied zu einer externen Middleware liegt im Zugang. Ein Tool wie n8n oder eine klassische iPaaS-Lösung sieht Shopware von außen, über die Admin-API und Webhooks. Nexus wird von Shopware selbst entwickelt und greift auf Ereignisse und Datenstrukturen des Shops zu, ohne dass dafür ein Plugin nötig ist. Shopware sagt außerdem zu, dass Workflows und Konnektoren über Shopware-Updates hinweg kompatibel bleiben. Das ist relevant, weil selbst gebaute Schnittstellen bei Hauptversionen regelmäßig Nacharbeit brauchen, etwa wenn sich Events oder Entity-Definitionen ändern.
Für die Einrichtung braucht es Shopware 6.7.1.0 oder neuer, einen Shopware-Account mit verknüpfter Firma und Admin-Zugang zum Shop. Wer noch auf 6.5, 6.6 oder 6.7.0 läuft, muss zuerst aktualisieren; die Reihenfolge beschreibt unser Update-Fahrplan für Shopware 6.
Nexus, Flow Builder, Plugin oder Middleware: Wer macht was
Shopware hat mit dem Flow Builder bereits ein Automatisierungswerkzeug. Er steuert Abläufe innerhalb des Shops, etwa eine Statusänderung oder eine Mail nach einer Bestellung. Ab dem Plan Evolve kann er per Webhook-Aktion auch Daten an Drittsysteme senden, allerdings ohne fertige Konnektoren zu ERP, PIM oder CRM. Nexus orchestriert Abläufe über Systemgrenzen hinweg. Plugins und Apps bleiben das Mittel, um Shopware selbst zu erweitern.
| Werkzeug | Wirkungsbereich | Typischer Einsatz | Betrieb |
|---|---|---|---|
| Flow Builder | innerhalb von Shopware, Webhook-Aktionen ab Evolve | Mail, Tag, Statuswechsel nach Ereignis | im Shop, im Plan enthalten |
| Shopware Nexus | Shopware ↔︎ externe Systeme | Bestellung ans ERP, Bestandsabgleich, Benachrichtigungen | Shopware-Dienst in der EU, Abrechnung pro Ausführung |
| Plugin / App | erweitert Shopware selbst | eigene Logik, Felder, Checkout-Anpassungen | im Shop, Wartung bei Updates |
| Externe Middleware (z. B. n8n, iPaaS) | beliebige Systeme untereinander | Mehrsystem-Prozesse, eigener Code, eingehende Webhooks | eigener oder fremder Server, eigene Wartung |
Überschneidungen gibt es beim Datenaustausch zwischen Shop und Drittsystem. Ob Nexus dort die bestehende Lösung ersetzen kann, hängt an den Konnektoren und an der Richtung der Datenflüsse.
Wie ein Nexus-Workflow aufgebaut ist
Ein Workflow besteht aus Knoten, die auf einer Arbeitsfläche per Drag-and-drop verbunden und in Projekten organisiert werden. Ausgelöst wird er entweder durch ein Shopware-Ereignis, zum Beispiel eine neue Bestellung (order.placed), oder durch einen Zeitplan im Cron-Rhythmus, etwa stündlich oder nachts.
Danach folgen Aktionen: Shopware-API-Aufruf, beliebiger externer API-Request, Business-Central-Operation, Slack-Nachricht, Shopware-E-Mail oder Ablage in S3. Dazu kommen Bedingungen (If/Else, Switch), ein Verzögerungsknoten und eine Datentransformation zum Mappen und Filtern von Feldern. Mit Platzhaltern in doppelten geschweiften Klammern werden Ereignisdaten in Nachrichten und Requests eingesetzt. Für ein Mapping von Bestellungen auf ERP-Aufträge reicht das. Staffelpreise oder Steuerberechnungen beschreibt die Dokumentation nicht; solche Logik gehört bis auf Weiteres nicht in Nexus.
Für Agenturen und Händler mit mehreren Shops ist ein Detail besonders nützlich: Workflows lassen sich exportieren und in einer anderen Umgebung importieren, wobei statt Zugangsdaten nur Integrations-IDs übertragen werden. Die API-Schlüssel bleiben also im jeweiligen Mandanten, gespeichert laut Dokumentation verschlüsselt. Knotenkonfigurationen wie Feld-Mappings lassen sich als Vorlage speichern und wiederverwenden.
Bei mehreren Firmen widersprechen sich die Quellen: Der Ankündigungsartikel und die Anwenderdokumentation beschreiben einen Organisations-Umschalter für getrennte Mandanten, die Getting-Started-Seite der Entwicklerdokumentation führt als Early-Access-Einschränkung, dass nur die erste verknüpfte Firma genutzt wird. Wer mehrere Organisationen plant, sollte das vorab im Portal klären.
Laut Shopware-Update vom 6. Oktober ist der Copilot in Nexus integriert, um Workflows in natürlicher Sprache zu erstellen, zu verbessern und zu debuggen. Die öffentliche Roadmap führt KI-generierte Workflows, KI-Debugging und automatische Datenmappings allerdings noch als „coming soon“. Für die Praxis ändert der Status wenig. Der Copilot baut einen Workflow schneller. Ob Mehrwertsteuer, Versandkosten und Rabatte korrekt im ERP ankommen, prüft er nicht.
Welche Systeme Nexus heute anbindet
Die Entwicklerdokumentation beschreibt als verfügbare Bausteine Microsoft Dynamics 365 Business Central (Lesen, Anlegen, Ändern, Löschen für Artikel, Kunden und Verkaufsaufträge), Slack, S3 und S3-kompatiblen Speicher, die Shopware-API sowie einen generischen API-Request für jedes externe System mit HTTP-Schnittstelle.
Die Produktseite nennt darüber hinaus Konnektoren für Odoo, NetSuite, ERPNext, Pimcore, Akeneo, Mailchimp, Klaviyo, Brevo und weitere. Auf der Shopware-Roadmap stehen dieselben Namen unter „Nexus: Upcoming Connectors“ mit dem Status „in Arbeit“, insgesamt 41 Einträge, darunter HubSpot, Zoho CRM und Google Sheets. Mit dem Oktober-Update kamen konfigurationsbasierte Konnektoren hinzu, die eigene Anbindungen mit weniger Programmcode ermöglichen sollen. SAP und Oracle führt die Entwicklerdokumentation erst unter „Post-GA“.
Die belastbare Arbeitsgrundlage für eine Shopware-ERP-Anbindung ist deshalb: Business Central ist als fertiger Konnektor dokumentiert. Jedes andere System mit erreichbarer REST-API lässt sich über den generischen API-Request anbinden, dann mit eigenem Mapping und eigener Fehlerbehandlung. Ob ein nativer Konnektor für dein ERP-System oder dein PIM zum Projektstart freigeschaltet ist, prüfst du im Nexus-Portal und nicht auf der Produktseite.
Die wichtigste Grenze: Die Richtung der Daten
Beide Grenzen aus der Einleitung begründet Shopware mit Sicherheitsbedenken: Es gibt derzeit keine eingehenden Webhooks und keinen eigenen Code. Nexus kann also auf Shop-Ereignisse reagieren und Daten aktiv abholen. Ein ERP, ein Logistiker oder ein Marktplatz kann eine Änderung aber nicht von sich aus an Nexus melden.
Für Lagerbestände ist das der Knackpunkt. Ändert sich ein Bestand im ERP, kommt die Änderung über Nexus nur per zeitgesteuertem Abruf in den Shop. Bei einem stündlichen Abgleich kann ein Artikel bis zu einer Stunde lang mit falschem Bestand verkäuflich sein. Bei 50 Artikeln mit großem Lager ist das egal, bei Abverkaufsware mit knappen Beständen nicht. Ein kürzerer Takt löst das Latenzproblem, kostet aber Ausführungen, wie der nächste Abschnitt zeigt.
Logik, die sich nicht mit den vorhandenen Knoten abbilden lässt, braucht weiterhin einen anderen Ort: ein Plugin im Shop, eine App oder eine Middleware.
Was Shopware Nexus kostet
Abgerechnet wird pro Ausführung, und eine Ausführung ist laut Nexus-Preisseite ein erfolgreich ausgeführter Knoten, nicht ein kompletter Workflow-Lauf. Jeder Shop erhält abhängig vom Shopware-Plan ein monatliches Kontingent, das am Monatsende verfällt und nicht übertragen wird. Darüber hinaus kosten 1.000 Ausführungen 10 Euro netto. Dieses Modell weist die Preisseite seit Oktober 2026 aus; zuvor stand dort eine kostenlose Einführungsphase. Ab welchem Stichtag tatsächlich abgerechnet wird, nennt Shopware nicht ausdrücklich.
| Shopware-Plan | Planpreis (netto, Liste) | Inklusive Ausführungen pro Monat |
|---|---|---|
| Community Edition | kostenlos | 100 |
| Rise | ab 600 € / Monat | 1.000 |
| Evolve | ab 2.400 € / Monat | 2.000 |
| Beyond | auf Anfrage | 5.000 |
Weil pro Knoten gezählt wird, rechnest du vom Workflow-Design aus. Eine Modellrechnung für einen Shop im Rise-Plan mit 1.500 Bestellungen im Monat, unter der Annahme, dass jeder Knoten einschließlich Auslöser zählt und angebrochene Blöcke voll berechnet werden:
- Bestell-Workflow mit vier Knoten: 4 × 1.500 = 6.000 Ausführungen.
- Stündlicher Bestandsabgleich mit drei Knoten: 24 × 30 × 3 = 2.160 Ausführungen.
Zusammen sind das 8.160 Ausführungen. Abzüglich der 1.000 inklusive bleiben 7.160, also acht 1.000er-Blöcke oder 80 Euro im Monat.
Läuft der Bestandsabgleich wegen knapper Bestände alle 15 Minuten, werden daraus 4 × 24 × 30 × 3 = 8.640 Ausführungen allein für diesen Workflow. Zusammen mit den Bestellungen sind das 14.640 Ausführungen, im Rise-Plan also 140 statt 80 Euro im Monat. Das ist der Preis für die fehlenden eingehenden Webhooks: Ein ERP, das Änderungen melden könnte, bräuchte keinen Abruf im Viertelstundentakt.
Offen ist in der öffentlichen Dokumentation, wie Knoten zählen, die über viele Datensätze laufen. Würde jeder Datensatz einzeln gezählt, ergäbe ein stündlicher Abgleich von 5.000 Artikeln mit einem verarbeitenden Knoten 720 × 5.000 = 3,6 Millionen Ausführungen im Monat.
Das ist eine Hypothese. Sie zeigt aber, warum die Zählweise im Pilot als Erstes geprüft wird und warum ein Abgleich nur geänderte Bestände übertragen sollte (Delta-Abgleich). Die Workflow-Metriken im Nexus-Portal zeigen die verarbeiteten Nachrichten pro Knoten; gleiche sie mit der ersten Abrechnung ab, bevor du hochrechnest.
In der Modellrechnung liegen die Ausführungsgebühren mit Delta-Abgleich zwischen 80 und 140 Euro im Monat. Teurer sind Aufbau, Mapping, Tests und die Pflege der Workflows. Genau dort setzt Shopware an und nennt bis zu 40 Prozent niedrigere Integrationskosten. Die Zahl stammt laut Fußnote aus internen Projektanalysen und Beta-Annahmen; eine unabhängige Messung gibt es nicht.
Reifegrad: Was „allgemein verfügbar“ heute bedeutet
Shopware hat Nexus am 28. Mai 2026 in einem Ankündigungsartikel mit dem Titel „enters general availability“ vorgestellt, in dessen Text von Early Access die Rede ist. Am 10. Juni folgte die Vorstellung auf dem Community Day, am 6. Oktober ein Update, das von der „general release“ spricht.
Die Entwicklerdokumentation nennt für die aktuelle Phase dagegen keine SLA-Garantien, keinen 24/7-Support, Betrieb nur in der EU ohne Self-Hosting oder On-Premise und noch keinen Marktplatz für Workflows.
Die Getting-Started-Seite listet weitere Early-Access-Einschränkungen, zwei davon zählen für die Planung: Es gibt keinen Testmodus, getestet wird mit Staging-Shops. Und Nachrichten werden mindestens einmal zugestellt („at-least-once“), Workflows sollen deshalb idempotent gebaut werden. Für eine Bestellübergabe heißt das: Das ERP darf denselben Auftrag bei einer Doppelzustellung nicht zweimal anlegen, zum Beispiel weil der Workflow vorher prüft, ob die Bestellnummer schon existiert.
Dass Nexus in der EU betrieben wird, vereinfacht die Datenschutzbewertung für den Dienst selbst. Wohin Daten danach fließen, bestimmen die angebundenen Zielsysteme. Das fehlende SLA ist dagegen ein echtes Kriterium, weil die Bestellübergabe ans ERP geschäftskritisch ist. Wiederholungen und Dead-Letter-Queue fangen Fehler der Zielsysteme ab; für einen Ausfall von Nexus selbst gibt es ohne SLA keine Zusage. Shopware richtet Nexus nach eigener Aussage vor allem an Entwickler und technische Teams, die Bedienung für Händler und Operations-Teams soll folgen.
Eine rollenbasierte Rechteverwaltung mit den Rollen Admin, Builder und Viewer beschreibt die Entwicklerdokumentation bereits. Weitere Betriebsfunktionen nennt bisher nur der Ankündigungsartikel. Ein Rate-Limiting-Knoten ist in Arbeit. Ein Circuit Breaker, der Anfragen bei gehäuften Serverfehlern eines Zielsystems drosselt, wird geprüft, ein Monitoring-Export etwa nach Grafana ist geplant.
Wann Nexus eine Middleware ersetzt und wann nicht
Am klarsten wird die Abgrenzung, wenn du die typischen Datenflüsse des Modellshops (Rise, 1.500 Bestellungen, stündlicher Abgleich) durchgehst:
- Bestellung → Business Central: passt. Der Fluss startet im Shop, der Konnektor ist dokumentiert, die Logik besteht aus Mapping und einer Bedingung.
- Bestand ERP → Shop: passt mit Einschränkung. Nur per Zeitplan, also mit Verzögerung und Ausführungskosten je Takt.
- Versandstatus vom Logistiker per Webhook → Shop: passt derzeit nicht. Das Drittsystem müsste aktiv melden; das bleibt Aufgabe einer Middleware oder eines Plugins.
Eine Middleware oder Eigenentwicklung bleibt außerdem die bessere Lösung, wenn SAP angebunden ist; dafür gibt es keinen nativen Konnektor. Dasselbe gilt, wenn Prozesse eigenen Code brauchen oder vertraglich ein SLA für die Schnittstelle gefordert ist. Für Prozesse, die mehrere Systeme ohne Shop-Bezug verbinden, etwa CRM, Buchhaltung und Ticketsystem, passt ein allgemeines Werkzeug wie n8n besser, weil Nexus auf Shopware als Mittelpunkt ausgelegt ist.
Unsere Empfehlung: neue, shopnahe Integrationen in Nexus aufbauen und bestehende, stabil laufende Shopware-Schnittstellen erst umziehen, wenn ohnehin eine Überarbeitung ansteht.
So prüfst du Nexus für deinen Shop
Eine Bewertung in fünf Schritten verhindert, dass die Entscheidung an der Konnektorliste oder am Preis hängen bleibt:
- Integrationsinventar erstellen: alle Datenflüsse zwischen Shop und Drittsystemen mit Richtung, Häufigkeit, Datenmenge und Kritikalität auflisten.
- Richtung prüfen: jeden Fluss markieren, der eingehende Webhooks oder eigenen Code braucht. Diese Flüsse bleiben vorerst außerhalb von Nexus.
- Konnektoren abgleichen: im Nexus-Portal prüfen, welche Systeme nativ verfügbar sind und welche über den generischen API-Request laufen müssten.
- Ausführungen schätzen: Knoten pro Workflow mal Auslösungen pro Monat, gegen das Kontingent deines Plans.
- Pilot auf einem Staging-Shop: Event-Ingestion-Service unter Einstellungen → Shopware Services aktivieren, Shop unter Einstellungen → Nexus verknüpfen und einen unkritischen Workflow aufsetzen, etwa eine Slack-Meldung bei Bestellungen über einem Schwellwert.
Im Pilot gezielt einen Fehler im Zielsystem auslösen und prüfen, ob der Lauf als fehlgeschlagen erscheint und sich wiederholen lässt. Eine Doppelzustellung simulierst du, indem du dasselbe Ereignis zweimal verarbeitest; das Zielsystem darf den Datensatz nur einmal anlegen. Parallel zählst du die verarbeiteten Nachrichten pro Knoten mit.
Erst wenn der Pilot stabil läuft, gehört ein geschäftskritischer Fluss wie die Bestellübergabe ans ERP in Nexus.
Häufige Fragen zu Shopware Nexus
Welche Shopware-Version brauche ich für Nexus?
Mindestens 6.7.1.0. Shops auf 6.7.0, 6.6 oder älter müssen vorher aktualisieren.
Zählt der Auslöser als Ausführung?
Das regelt die öffentliche Dokumentation nicht. Die Modellrechnung oben zählt ihn vorsichtshalber mit; Klarheit bringt die erste Abrechnung aus dem Pilot.
Ersetzt Nexus den Flow Builder?
Nein. Der Flow Builder bleibt für Automatisierungen innerhalb des Shops zuständig. Nexus kommt dazu, wenn Daten gemappt, wiederholt zugestellt oder an mehrere externe Systeme verteilt werden sollen.
Kann ich Nexus selbst hosten?
Nein. Nexus läuft als Dienst von Shopware in der EU, Self-Hosting ist nicht vorgesehen.
Fazit: Für wen sich Shopware Nexus heute lohnt
Nexus schließt die Lücke zwischen Shop und Drittsystem mit direktem Zugriff auf Shop-Ereignisse, Betrieb in der EU, Wiederholungslogik und Gebühren, die bei sauberem Workflow-Design überschaubar bleiben. Für neue Integrationen, die im Shop starten oder per Zeitplan abholen, ist Nexus heute eine ernsthafte Option. Für eingehende Echtzeit-Daten, SAP-Landschaften und Prozesse mit eigener Logik ist es das noch nicht.
Fang deshalb mit dem Pilot aus Schritt 5 an, bevor du eine Migration planst. Wenn du dabei oder beim Abgleich deiner bestehenden Schnittstellen Unterstützung willst, begleiten wir dich als Shopware-Agentur von Inventar über Pilot bis Umsetzung.
