Wenn dein Shop nur eine Insel ist, verschenkst du Geld. Die wertvollsten Daten liegen in anderen Systemen: Produkte im PIM, Kundenhistorie im CRM, Lagerbestände im ERP. Shopware lässt sich mit diesen Systemen verbinden, wenn du weißt wie. Einen umfassenden Überblick bietet auch unser Artikel zur ERP-Integration im E-Commerce.
Das klingt einfacher als es ist. Die meisten Shopware-Integrationen scheitern nicht an der Technologie, sondern an falschem Ansatz. Directintegration oder Middleware. Admin API oder Store API. Sync oder Event-driven. Diese Entscheidungen machen den Unterschied zwischen einem stabilen System und einem Produktionsfehlern-Dauerbrenner.
Wir bauen solche Integrationen seit über 10 Jahren. Hier ist was wir gelernt haben.
Inhalt
- Die Shopware API-Landschaft: Wo verbindest du dich an?
- Admin API vs. Store API: Das ist der Unterschied
- Das Shopware App System: Die neue Integration-Welt
- Directintegration oder Middleware? Wann du welche brauchst
- ERP anbinden: So funktioniert es praktisch
- PIM-Integration in Shopware 6: Mehr als nur Daten-Sync
- CRM und Shopware: Customer Data richtig verbinden
- Die häufigsten Integrations-Fehler und wie du sie vermeidest
Die Shopware API-Landschaft: Wo verbindest du dich an?
Shopware ist ein System mit drei verschiedenen Eingängen für externe Systeme. Für jeden Anwendungsfall gibt es den richtigen.
Admin API: Für alles was intern laufen soll. Produktdaten ändern, Bestände updaten, Kunden hinzufügen, Bestellungen verarbeiten. Benötigt OAuth 2.0 Authentifizierung und ist REST-basiert. Du authentifizierst dich mit Client ID und Client Secret und bekommst einen Token. Das ist wie mit jedem modernen API-System.
Store API: Für kundennahe Operationen. Warenkorb, Checkout, Suche, Filter. Diese API ist teilweise öffentlich (Shopping-Operationen) und teilweise authentifiziert (Kundendaten). Die meisten Headless-Frontends (Nuxt, Next.js, React) sprechen mit der Store API.
App System / Webhooks: Das Neue der Integration. Statt zu pollend (ständig "Hey, gibt es was Neues?") funktioniert das über Events. Wenn in Shopware etwas passiert (Bestellung erstellt, Produkt geändert, Lagerbestand angepasst), schickt Shopware das zu dir. Das ist effizienter, schneller und weniger fehleranfällig. Das App System ist die native Anbindung für externe Tools.
Die richtige Wahl: Wenn du Produktdaten syndizieren musst, ERP-Bestände abfragen oder Kunden migrieren willst, brauchst du Admin API. Für Checkout-Logik und Personalisierung brauchst du Store API. Für Events und Echtzeit-Reaktionen (z.B. "Bestellung eingegangen, sofort ins ERP") nutzt du das App System mit Webhooks.
Admin API vs. Store API: Das ist der Unterschied
Die beiden APIs sind nicht Konkurrenten. Sie lösen verschiedene Probleme.
Admin API ist die Verwaltungs-API. Sie sieht alle Daten, kann alles ändern. Inventory, Preise, Kunden, Bestellungen, Kategorien. alles manipulierbar. Dafür ist sie kein Public API. Du brauchst einen Access Token und die Requests kommen von einer vertrauenswürdigen Quelle (dein ERP, dein PIM, dein Middleware-System).
Die Admin API läuft über OAuth 2.0. Das bedeutet: Du registrierst eine Integration, bekommst Client ID und Secret, authentifizierst dich, bekommst einen Token mit Ablaufdatum, sendest Requests mit diesem Token. Standard Enterprise-Flow.
Store API ist für Kunden gedacht. Sie bietet einen Subset der Daten. die Dinge die ein Kunde sehen soll. Produkte, Kategorien, sein Profil, sein Warenkorb. Aber nicht die Kosten-Kalkulation, nicht die Kundensegmente, nicht interne Notizen. Die Store API ist teilweise öffentlich (GET-Requests für Produkte brauchen keine Auth), teilweise authentifiziert (GET dein Profil, POST Warenkorb-Item).
Die Store API ist für Frontends gedacht. Wenn du ein Nuxt-Frontend brauchst das nicht mehr Shopware-Template ist, sondern eine echte Headless-Lösung, redest dein Frontend mit der Store API.
Das ist der entscheidende Unterschied: Admin API = Backend-Systeme sprechen mit Shopware. Store API = Kundenfrontend spricht mit Shopware. Für Integrationen (ERP, PIM, CRM) brauchst du fast immer die Admin API.
Das Shopware App System: Die neue Integration-Welt
Shopware 6 hat ein natives App System. Das ist nicht "ein Marktplatz mit vorgefertigten Plugins". Das ist eine Architektur für externe Integrationen.
Eine Shopware App läuft auf separaten Systemen (nicht im Shop-Server installiert). Sie kommuniziert über REST API und Webhooks mit dem Shop. Das ist ein großer Unterschied zu Plugins. Plugins sind PHP-Code der direkt im Shop lauft. Apps sind externe Systeme die der Shop ruft, oder die vom Shop gerufen werden.
Das App System ist die native Antwort auf Fragen wie: "Wie integriere ich mein ERP?" oder "Wie baue ich Preise dynamisch aus meinem PMS in den Shop?"
Webhooks sind der Kern. Wenn eine Bestellung erstellt wird, löst Shopware einen Webhook zu deiner App aus. Deine App reagiert (z.B. schickt die Bestellung ins ERP, erstellt eine Rechnung, aktualisiert den Lagerbestand). Das ist ereignisgesteuerte Architektur, deutlich effizienter als ständiges Abfragen.
Das App System ist auch die Heimat für den Shopware Integration Hub. Das ist kein Produkt sondern eine Sammlung vorgefertigter Integrationen (ERP-Systeme, Payment-Provider, Shipping-Gateways). Wenn dein ERP im Hub vorhanden ist, installierst du die App und sie funktioniert meist von Haus aus.
Directintegration oder Middleware? Wann du welche brauchst
Das ist die nächste Entscheidung die viele Projekte verzweifeln lässt. In unseren Projekten sehen wir beide Ansätze. Die Wahl hängt von der Systemlandschaft ab, nicht von persönlichen Vorlieben.
Directintegration: Dein ERP spricht direkt mit der Admin API. Keine Zwischenschicht. Dein ERP ist der "aktive" Partner. es zieht Daten oder pusht Updates direkt in Shopware.
Vorteile: Einfach, weniger Systeme, direkt. Nachteile: Jedes ERP-System braucht eigene Logik für Shopware, weniger Flexibilität für komplexe Mappings.
Middleware: Ein separates System (Synesty, Alumio, eine Custom Node.js App) sitzt zwischen Shopware und dem ERP. Das Middleware-System transformiert Daten, mapped Felder, steuert den Workflow.
Vorteile: Du kannst dein ERP-System austauschen ohne die Shopware-Anbindung zu ändern. Komplexe Transformationen sind einfacher. Du kannst mehrere Systeme (ERP + PIM + CRM) an ein Middleware anschließen. Nachteile: Zusätzliches System das gepflegt werden muss. Kosten. Wenn das Middleware-System down ist, läuft nix mehr.
Die Faustregel: Für ein Projekt mit einem ERP und einfachen Daten-Mappings brauchst du kein Middleware. Directintegration über Admin API oder ein vorgefertigtes App.
Wenn du mehrere Systeme anbinden musst (ERP + PIM + CRM), oder wenn die Daten-Transformationen komplex sind (z.B. "Wenn Kundengruppe = VIP und Kategorie = Elektronik dann dieser Preis"), dann spart dir Middleware langfristig Nerven und Geld.
ERP anbinden: So funktioniert es praktisch
Das häufigste Integrations-Szenario. Shopware-Bestellen müssen ins ERP, ERP-Bestände und Preise müssen in Shopware aktuell sein.
Das Szenario. Ein Kunde bestellt im Shop. Was soll passieren?
- Bestellung in Shopware erstellt
- Webhook wird ausgelöst (wenn du das so konfiguriert hast)
- Dein Integrations-System (Directintegration oder Middleware) bekommt den Webhook
- Dein System validiert die Daten, mapped sie ins ERP-Format
- ERP-API wird aufgerufen, Bestellung wird erstellt
- ERP antwortet mit Auftragsnummer, Verfügbarkeitsstatus
- Dein System updatet Shopware mit dieser Info (z.B. verfügbar ja/nein, Liefertermin)
Das ist asynchron. Das ist wichtig. Der Kunde sieht nicht "warte auf ERP-Antwort". Das würde den Shop zu langsam machen. Der Webhook läuft im Hintergrund (asynchron) und updatet Shopware sobald die ERP-Daten vorliegen.
Beispiel: SAP oder Microsoft Dynamics.
SAP und Microsoft Dynamics haben beide REST-APIs. Für die Bestell-Integration brauchst du typischerweise:
- Bestellung-Daten mappen (Shopware-Feldnamen ins SAP-Format)
- Validierung (Kundennummer existiert in SAP ja/nein)
- Error Handling (Was passiert wenn SAP sagt "Kunde nicht aktiv"?)
- Rücksync (SAP aktualisiert Shopware mit Lieferdatum, Tracking-Nummer)
Das kann directintegration sein (dein SAP-System hat einen Connector für Shopware-Webhooks) oder Middleware (ein API-Gateway das zwischen SAP und Shopware sitzt und beide Sprachen spricht).
Best Practice: Nicht die ganze SAP in den Shop integrieren. Nur das was du brauchst. Bestellen, Lagerbestände, Preise. Nicht die interne Finanzplanung oder HR-Daten. Das ist ein klassischer Fehler: "Lass uns alles synchron halten" führt zu Komplexität und Fehlern.
PIM-Integration in Shopware 6: Mehr als nur Daten-Sync
PIM (Product Information Management) ist wo deine Masterdaten leben sollen. Ein Produkt mit 50 Attributen, 20 Bilder, 8 Sprachen. das gehört ins PIM, nicht in den Shop.
Shopware als PIM zu missbrauchen ist verbreitet und ein Fehler. Shopware kann Produkte speichern, ja. Aber es ist nicht gemacht um komplexe Produktdaten-Governance zu handhaben. Was ein PIM im E-Commerce leistet und wann es sinnvoll ist, erklären wir in einem eigenen Artikel.
Das richtige Setup: Produkte im PIM (Akeneo, Pimcore), Shopware als Verkaufskanal.
Das bedeutet:
- PIM ist die Quelle der Wahrheit (Source of Truth)
- Der Shop zieht sich nur die Daten die er braucht
- Wenn ein Produkt im PIM aktualisiert wird, wird es im Shop aktualisiert
- Shopware-spezifische Daten (Kategorie-Zuordnung, SEO-Texte für den Channel Shop) können im Shop zusätzlich gespeichert werden
Akeneo + Shopware Beispiel.
Akeneo ist das verbreitetste Open-Source PIM. Die Integration funktioniert meist über:
- Akeneo hat eine REST API
- Ein Middleware (oder ein Custom Connector) zieht Produkte aus Akeneo
- Mapper transformiert Akeneo-Felder ins Shopware-Format
- Admin API wird aufgerufen um Produkte zu erstellen/updaten
- Bilder werden von Akeneo-Server zu Shopware hochgeladen
Das ist regelmäßig, nicht live. Typischerweise läuft das einmal pro Nacht oder nach manuellem Trigger.
Pimcore + Shopware.
Pimcore ist ein großes System. PIM, DAM, MDM, CDP in einem. Für die Shopware-Integration ist Pimcore ein External-System das Shopware mit Produktdaten versorgt.
Komplexere Integration als Akeneo meist, weil Pimcore mehr Features hat. Dafür auch deutlich mächtiger wenn du Multi-Channel-Publishing brauchst (nicht nur Shop, sondern auch B2B-Portal, App, Händler-Portal).
CRM und Shopware: Customer Data richtig verbinden
CRM ist einfacher zu integrieren als ERP, aber konzeptionell kniffliger: Welche Daten gehören wohin?
Das Szenario. Ein Kunde kauft im Shop. Diese Daten sollen ins CRM (Salesforce, HubSpot). CRM hat die Kundenhistorie und soll diese an Shopware weitergeben (z.B. für Personalisierung, für Segment-Zugriff).
Die Richtung. Shop → CRM ist einfach. Kundenprofil, Kaufhistorie, E-Mail-Adresse. Das sind Events die der Shop nach außen kommuniziert. Webhooks für "Kunde registriert sich", "Bestellung erstellt", "Kunde klickt Review-Button".
CRM → Shop ist komplizierter. Das CRM hat Kundengruppen, Scoring, Lifecycle-Stage. Das soll der Shop wissen um personalisiert zu sein. Dafür brauchst du ein System das regelmäßig CRM-Daten abzieht und in Shopware synct. Oder einen Custom-Store-API-Endpoint der aus dem CRM Daten abfragt (Achtung: Performance!).
Salesforce Integration.
Salesforce hat Marketing Cloud Connect und eine REST API. Typischerweise:
- Shopware löst Webhooks bei Registrierung, Kauf, Review aus
- Ein Middleware (oder eine AWS Lambda Funktion) fängt das ab
- Daten werden ins Salesforce-Format gemappt (Shopware-Customer → Salesforce-Contact)
- Salesforce API wird aufgerufen
- Rückrichtung: Nachts lädt ein Batch-Job Kundengruppen/Segment-Info aus Salesforce und synct sie in Shopware (über Admin API)
HubSpot Integration.
HubSpot ist kleiner und einfacher. HubSpot hat vorgefertigte Shopify-Integration, für Shopware musst du Custom bauen. Aber HubSpot API ist entwicklerfreundlich.
Typischer Workflow:
- Webhooks für Kauf/Registrierung
- Daten in HubSpot-Kontakt synced
- HubSpot Automationen reagieren (z.B. "Automatisch eine Kampagne starten wenn jemand eine Kategorie angesehen hat")
- Wenn du Rücksync brauchst (HubSpot-Segment zurück in Shop): Separat konfigurieren, nicht automatisch
Die häufigsten Integrations-Fehler und wie du sie vermeidest
Wir haben viele Integrationen repariert die in anderen Projekten schiefgelaufen sind. Das sind die Top-Fehler:
Fehler 1: Synchron denken statt asynchron.
Ein klassischer Fehler. Der Webhook wird ausgelöst, Shopware wartet auf ERP-Antwort, der Kunde sieht eine Loading-Animation. Das ist langsam und fragil. Wenn das ERP-System mal 30 Sekunden braucht oder offline ist, sieht der Kunde einen Error.
Richtig: Webhook läuft asynchron im Hintergrund. Der Kunde sieht sofort "Bestellung aufgegeben". Das Hintergrund-System synchronisiert die Daten mit ERP, und wenn das länger dauert oder fehlschlägt, ist das kein Customer-Problem. das ist ein Admin-Problem das nachts aufgelöst wird.
Fehler 2: Alle Daten synchen wollen.
"Lass uns einfach alles synchen damit alles aktuell ist." Das führt zu Komplexität, Performance-Problemen und Debugging-Albträumen. Was du brauchst: Nur die Daten synchen die für den Use Case essentiell sind. Für Bestellungen: Kundenname, Adresse, Artikel, Menge, Preis (nicht die Kundenhistorie oder den Browsing-Verlauf).
Fehler 3: Keine Error-Handling.
Was passiert wenn der Webhook-Request fehlschlägt? Wenn Netzwerk weg ist? Wenn das ERP antwortet mit "Kunde existiert nicht"? Das muss explizit gehandelt werden. Retry-Logik, Fallback-Verhalten, Error-Logging.
Viele Integrations-Projekte bekommen das nicht hin und enden mit "Irgendwelche Bestellungen verschwinden sporadisch". Das ist nicht Shopware-Bug sondern schlechtes Error Handling.
Fehler 4: Testing und Monitoring vergessen.
Die Integration funktioniert mit Testdaten. Aber was ist wenn die Kartennummer ungültig ist? Wenn der Kunde nicht aktiv im ERP ist? Das sollte getestet sein, bevor es live geht.
Und dann Monitoring: Wie siehst du ob Integration noch läuft? Wenn täglich 1000 Bestellungen synced werden sollten und plötzlich nur noch 50 ankommen, wann merkst du das? Logging und Monitoring braucht man.
Fehler 5: Middleware für einfache Szenarien bauen.
Manchmal wird ein komplexes Custom-Middleware-System gebaut wenn ein einfacher App-Connector gereicht hätte. Das ist Über-Engineering. Die Faustregel: Start mit der einfachsten Lösung die funktioniert. Wenn das zu kompliziert wird, dann Middleware.
Fazit: Integration ist nicht Magie, aber auch nicht trivial
Integrationen sind das Gegenteil von der Insel-Shop. Sie verbinden deine Systeme und machen Shopware zum Verkaufskanal statt zum Data-Silos. Wer dabei auf Prozessautomatisierung setzt, kann viele dieser Datenflüsse effizient ohne manuellen Aufwand betreiben.
Die richtige Architektur: Identifizieren was du brauchst (ERP-Bestände? PIM-Produkte? CRM-Segmente?). Dann entscheiden ob Directintegration oder Middleware. Webhooks und asynchrone Verarbeitung sind der Standard. Und fehlertoleranz, Monitoring, Test-Coverage müssen drin sein.
Das ist nicht kompliziert wenn du die Basics verstanden hast. Und wenn dein Team sich ernsthaft damit auseinandersetzt.