Shopware Nexus: Was sich für Agenturen jetzt ändert

Mehr als die Hälfte des Implementierungsaufwands in Commerce-Projekten fließt nicht in den Shop, sondern in die Verbindung zwischen Systemen. Das ist kein neues Problem. Neu ist, dass Shopware auf dem Community Day 2026 (10. Juni) eine Antwort präsentiert hat: Shopware Nexus, eine native, eventgetriebene Orchestrierungsschicht, die fragile Middleware durch visuelle Workflows ersetzt. Und dazu eine vollständige MCP-Abdeckung, die Shopware-Aktionen für KI-Agenten erreichbar macht.

Was Sie in 9 Minuten erfahren:

Was Shopware Nexus konkret kann, wie es sich vom Flow Builder unterscheidet und was Early Access voraussetzt
Was vollständige MCP-Abdeckung für Shopware bedeutet und warum der Praxis-Case Avisena Med zeigt, wie das heute schon funktioniert
Welche Architektur-Entscheidungen Sie jetzt treffen sollten und welche Sie noch aufschieben können

Auf dem SCD 2026 formulierte Co-CEO Sebastian Hamann die strategische Frage: "Wenn Maschinen anfangen zu kaufen, was macht Händler dann noch interessant?" Seine Antwort: Zwei parallele Realitäten. Für KI-Agenten braucht es MCP, agentenkompatible APIs und Workflow-Automatisierung. Für menschliche Käufer braucht es Emotion, Vertrauen und Markenerlebnisse. Nexus adressiert die erste Realität. Dieser Artikel ordnet ein, was das technisch bedeutet.

Shopware Nexus auf einen Blick

Aspekt	Shopware Flow Builder	Shopware Nexus
Fokus	Shop-interne Logik	Systemübergreifende Prozesse
Typischer Use-Case	Status-E-Mail bei Bestelleingang	Bestellung → ERP → Lager → Slack
Middleware nötig?	Nein	Nein (Nexus ersetzt Middleware)
Architektur	Sequentiell, fest verdrahtet	Eventgetrieben, AI-powered
Wiederverwendbarkeit	Pro Shop	Über Shops und Kunden hinweg
Status	Produktiv	Early Access / Beta (6.7.1.0+)
Voraussetzung	Shopware 6	Shopware 6.7.1.0+ + aktives Abo

Betrifft Sie das? Schnelltest in 30 Sekunden

Sofort relevant wenn: Ihre Shopware-Projekte ERP-, CRM- oder PIM-Anbindungen haben und diese über Custom-Middleware laufen. Nexus ist für genau dieses Setup gebaut.

Early Access evaluieren wenn: Sie mehrere Shopware-Kunden betreuen und wiederverwendbare Integrations-Workflows anbieten wollen. Das ist der stärkste Wettbewerbsvorteil von Nexus für Agenturen.

Noch nicht akut wenn: Ihre Shopware-Projekte ohne externe System-Anbindungen laufen. Flow Builder reicht dann für interne Automatisierungen weiterhin vollständig.

Kommt Ihnen das bekannt vor?

Custom-Middleware zwischen Shopware und ERP, die nach jedem Major-Update bricht. Ich helfe Ihnen einzuschätzen, ob Nexus die richtige Ablösung ist.

Shopware-Integrationsprojekte seit Jahren
ERP, CRM, PIM-Anbindungen aus der Praxis

Kostenlosen Check anfragen →

⏱️ Antwort binnen 24 Stunden

Was macht Shopware Nexus technisch?

Nexus ist eine native Orchestrierungsschicht auf demselben PHP/Symfony-Stack wie Shopware Core. Das ist der entscheidende Unterschied zu generischer Middleware (n8n, Zapier, Make): Nexus kennt Shopware-Entities, -Events und -APIs direkt, ohne Adapter-Layer. Das reduziert Integrationskosten und eliminiert einen ganzen Klassen von Upgrade-Brüchen.

Das Prinzip: Shopware-Events (eine neue Bestellung, eine Lageränderung, ein Cron-Trigger) lösen Workflows aus. Die Workflows werden im Drag-and-Drop-Canvas zusammengebaut. Kein Custom-Code für Routineintegration.

# Beispiel-Workflow (konzeptuell, Canvas-basiert):

Trigger: order.placed
↓
[Conditional Logic] Bestellwert > 1.000€?
↓ Ja
[Shopware API] Kundenstatus prüfen
↓
[MS Dynamics Business Central] Sales Order erstellen
↓
[Data Transformation] Referenznummer extrahieren
↓
[Shopware API] Bestellung mit BC-Referenz aktualisieren
↓
[Slack] Nachricht in #sales-channel senden

# Heute verfügbare Konnektoren:
# - Shopware Events (Trigger)
# - Shopware API (CRUD)
# - Microsoft Dynamics Business Central (CRUD)
# - Slack (Nachrichten)
# - Beliebige HTTP-API (generischer Konnektor)
# - Conditional Logic, Data Transformation, Expression Placeholders

Was die offizielle Dokumentation nicht prominent platziert: Nexus-Workflows haben Zustände. Entwurf, Veröffentlicht, Aktiv, Wird bereitgestellt. Das ist wichtig für Agentur-Projekte, die Staging-Umgebungen nutzen. Workflows müssen bewusst veröffentlicht und gestartet werden, kein automatisches Aktivieren nach Deployment.

KurzNexus ist Middleware-Ersatz direkt in Shopware. Eventgetrieben, visuell, wiederverwendbar. Für Agenturen mit mehreren ERP-Integrationsprojekten der stärkste Hebel.

Was bedeutet vollständige MCP-Abdeckung für Shopware?

Auf dem SCD 2026 wurde MCP-Abdeckung als Voraussetzung für KI-Agenten-Handel benannt. Was das konkret heißt: Shopware-Admin-Aktionen (Produkte anlegen, Bestände abfragen, Bestellungen verwalten) werden über das Model Context Protocol für MCP-fähige Clients erreichbar. Claude Code, Cursor, GitHub Copilot und andere KI-Agenten können dann direkt mit Shopware interagieren.

Das ist kein Zukunftsszenario. dotfly. hat im Februar 2026 für ihren Kunden Avisena Med einen Shopware Admin MCP-Server aufgebaut, über einen Cloudflare Worker, mit Claude Code als Agent. Wie ich im PHPverse-2026-Artikel beschrieben habe, hat das offizielle MCP-PHP-SDK (PHP Foundation, Symfony, Anthropic) die Infrastruktur dafür geliefert.

# Shopware Admin MCP-Server: Konzept (nach dotfly.-Ansatz)
# 1. OAuth-App in Shopware anlegen (Admin API)
# 2. MCP-Server als Cloudflare Worker oder PHP-App implementieren
# 3. Tools definieren: getProduct, updateStock, listOrders, ...
# 4. MCP-Client (Claude Code, Cursor) verbindet sich

# Beispiel: Claude Code kann dann per natürlicher Sprache:
# "Zeig mir alle Bestellungen mit Status 'Bezahlt' vom heute"
# "Aktualisiere den Lagerbestand von SKU SW-12345 auf 150"
# "Erstelle ein Produkt mit Name, Preis und Kategorie"

# Berechtigungen: OAuth-Scopes müssen exakt definiert sein.
# Keine Admin-Vollrechte für den MCP-Client empfohlen.

Was die Shopware-Ankündigung als "vollständige MCP-Abdeckung" noch nicht vollständig definiert: Ob es eine offizielle, gepflegte Shopware-MCP-Integration geben wird, oder ob das Ökosystem-Lösungen baut. Der Praxis-Case zeigt, dass beides funktioniert.

MCP und Nexus sind unterschiedliche Layer: Nexus automatisiert System-zu-System-Prozesse (Shopware → ERP → Slack). MCP macht Shopware-Admin für KI-Agenten bedienbar (Claude Code → Shopware). Beide ergänzen sich, lösen aber verschiedene Probleme.

KurzMCP-Abdeckung macht Shopware-Admin für KI-Agenten bedienbar. Der Praxis-Beweis existiert. Die Frage ist nicht ob, sondern wann das in Standard-Projekte wandert.

⚡ Shopware-Integration modernisieren?

Ich helfe Ihnen einzuschätzen, ob Nexus Ihre bestehende Middleware ablösen kann und was MCP-Abdeckung für Ihre Shopware-Projekte bedeutet.

Shopware-Integrationen mit ERP, CRM, PIM
MCP-Server-Implementierung für Shopware

Architektur besprechen →

⏱️ Antwort binnen 24 Stunden

📞 Oder direkt anrufen: 04481 - 9099658

Welche Entscheidungen sollten Sie jetzt treffen?

Was jetzt sinnvoll ist

Early Access beantragen, wenn Sie aktive Shopware-ERP-Projekte haben. Das Beta-Feedback beeinflusst die Roadmap und Sie kennen die Plattform, bevor GA erscheint. Voraussetzung: Shopware 6.7.1.0+ und aktives Abonnement.

Nexus für neue Integrationsprojekte evaluieren. Wenn ein Shopware-Kunde gerade eine ERP-Anbindung plant, ist Nexus der richtige Moment für einen Proof-of-Concept statt Custom-Middleware zu bauen.

MCP-Architektur im Blick behalten. Der Praxis-Case dotfly./Avisena Med zeigt: Ein Shopware Admin MCP-Server ist in wenigen Tagen buildbar. Der Aufwand ist überschaubar, der strategische Vorteil für Agenturen, die KI-Tooling in ihre Shopware-Arbeit integrieren wollen, ist real.

Was Sie noch aufschieben können

Bestehende, stabile Custom-Middleware migrieren. Nexus ist in der Beta. GA-Termin nicht kommuniziert. Wer eine laufende, stabile ERP-Integration hat, sollte nicht jetzt migrieren, sondern warten bis GA und die ersten Produktiv-Erfahrungen vorliegen.

Vollständige MCP-Abdeckung für bestehende Projekte. Solange Shopware keine offizielle, gepflegte MCP-Integration liefert, ist der Aufwand projektspezifisch. Für neue Projekte mit KI-Agenten-Anforderungen: sofort evaluieren.

Aus meiner Erfahrung mit Shopware-Integrationsprojekten: Der häufigste Fehler ist nicht zu früh oder zu spät migrieren, sondern keine bewusste Entscheidung zu treffen. Nexus in der Beta zu ignorieren bedeutet, bei GA unter Zeitdruck zu evaluieren.

Aus der Praxis

Was mir bei Code-Reviews und Einarbeitungen in Shopware-Bestandsprojekte häufig begegnet: Custom-Middleware, die bei jedem Shopware-Major-Update bricht und dann im Nachhinein repariert wird. Oft sind das PHP-Scripts, die direkt auf Shopware-Datenbanktabellen zugreifen statt die API zu nutzen, oder n8n-Flows, die Shopware-interne APIs abgreifen. Als Shopware-Entwickler, der regelmäßig in Bestandsprojekte einarbeitet, sehe ich Nexus als die strukturelle Antwort auf dieses Problem. Aber erst wenn es stabil ist.

Zusammenfassung

Shopware Nexus ersetzt fragile Custom-Middleware durch eine native, eventgetriebene Orchestrierungsschicht. PHP/Symfony-Stack, visueller Canvas, wiederverwendbare Workflows. Early Access mit Shopware 6.7.1.0+ und aktivem Abonnement. GA-Termin noch nicht kommuniziert.

Flow Builder vs. Nexus: Flow Builder für Shop-interne Logik. Nexus für systemübergreifende Prozesse (ERP, CRM, PIM, Slack). Keine Konkurrenz, sondern Ergänzung.

MCP-Abdeckung macht Shopware-Admin für KI-Agenten bedienbar. Der Praxis-Case dotfly./Avisena Med zeigt: Shopware Admin MCP-Server funktioniert heute mit Claude Code. Das ist kein Pilot, das ist Produktion.

Laut Shopware fließt mehr als die Hälfte des Projektaufwands in System-Integrationen statt in Differenzierung. Nexus ist die Antwort darauf. Die Zahl stammt aus Shopwares eigener Pressemitteilung und ist noch nicht unabhängig verifiziert.

Sie wissen, welche Integrations-Schulden Ihr Shop mit sich trägt.

Nexus Early Access, MCP-Abdeckung oder Architektur-Review. Lassen Sie uns klären, was für Ihr Projekt der richtige nächste Schritt ist.

Shopware-Integrationen: ERP, CRM, PIM
MCP für Shopware seit dem ersten Praxis-Case
Early-Access-Evaluation und Beta-Feedback

Nächsten Schritt klären →

Häufige Fragen

Ersetzt Shopware Nexus den Flow Builder?

Nein. Flow Builder und Nexus lösen unterschiedliche Probleme. Flow Builder bleibt für Shop-interne Automatisierungen: Status-E-Mails, interne Aktionen nach Bestelleingang, Tag-Vergabe an Kunden. Nexus übernimmt systemübergreifende Prozesse zwischen Shopware und externen Systemen (ERP, CRM, PIM, Slack). Beide Werkzeuge koexistieren und ergänzen sich.

Was kostet Shopware Nexus?

Shopware hat keine separaten Nexus-Preise kommuniziert. Early Access setzt ein aktives Shopware-Abonnement voraus. Die finale Preisstruktur für GA ist noch nicht bekannt. Für Agenturen mit Shopware-Evolution-Plan oder Commercial-Abonnement dürfte Nexus Teil des bestehenden Abonnements sein, aber das ist noch nicht bestätigt.

Kann ich Nexus mit meinem bestehenden ERP nutzen?

Heute offiziell unterstützt: Microsoft Dynamics Business Central und generische HTTP-APIs. Über den HTTP-Konnektor können prinzipiell alle REST-APIs angebunden werden, also auch SAP, DATEV-Connect, oder eigene ERP-Systeme mit API. Direkte native Konnektoren für SAP oder andere ERP-Systeme sind noch nicht kommuniziert. Das Ökosystem wird nach GA wachsen.

Was ist der Unterschied zwischen Shopware Nexus und n8n/Make/Zapier?

n8n, Make und Zapier sind generische Workflow-Automatisierungstools, die Shopware als einen von vielen Konnektoren kennen. Nexus ist nativ in Shopware: Es kennt Shopware-Entities, Events und APIs direkt. Das eliminiert Adapter-Layer, reduziert Upgrade-Risiken und ermöglicht Daten-Transformationen mit Shopware-Kontext. Für reine Shopware-ERP-Integrationen ist Nexus der sauberere Ansatz. Für Multi-System-Workflows außerhalb von Shopware können generische Tools weiterhin sinnvoll sein.

Wie baue ich einen Shopware Admin MCP-Server?

Das grundlegende Setup: Shopware OAuth-App mit Admin-API-Berechtigungen anlegen, MCP-Server als PHP-App oder Cloudflare Worker implementieren, Tools für Shopware-Aktionen definieren (Produkte, Bestellungen, Lager). Das offizielle MCP-PHP-SDK (mcp/sdk) liefert die Infrastruktur. Der Praxis-Case dotfly./Avisena Med zeigt, dass das in wenigen Tagen buildbar ist. Der kritische Punkt: Berechtigungen granular definieren, keine Admin-Vollrechte für den MCP-Client.

Artikel teilen: