Sie haben einen Shopware 6 Shop und wollen ein eigenes Frontend mit Vue, React, Next oder Nuxt bauen. Willkommen in der Headless Welt. Hier trennen Sie Shop-Logik und Storefront, holen sich alle Daten über die API und gestalten das Frontend genau so, wie Sie es brauchen. Klingt nach viel Freiheit. Ist es auch. Aber ohne Plan wird es schnell wild.
In diesem Beitrag zeige ich Ihnen, wie Sie Headless Commerce mit Shopware 6 strukturiert angehen. Sie lernen, wie die APIs aufgebaut sind, wie Sie Ihr Frontend Framework sauber mit dem Shop verbinden und welche Fallen Sie sich bitte sparen. Das Ganze aus Sicht einer Entwicklerin, die gern lacht, aber bei Architekturen keine Kompromisse mag.
Wenn Sie noch tiefer in das Thema Headless Commerce mit Shopware 6 einsteigen wollen, lohnt sich ein Blick in die offizielle Übersicht zu Headless Commerce bei Shopware. Dort bekommen Sie einen guten Gesamtblick auf die Headless Fähigkeiten der Plattform.
Was bedeutet Headless Commerce mit Shopware 6 konkret
Headless Commerce meint die harte Trennung zwischen Backend und Frontend. Shopware 6 kümmert sich um Produkte, Preise, Kundendaten, Warenkorb und Checkout. Ihr Frontend Framework ruft diese Daten über die API ab und präsentiert sie auf Website, App oder im Kiosk im Store. Die Kommunikation läuft über klar definierte Endpunkte und JSON. Keine Templates aus dem Core. Keine Twig Schleifen im Shopware Theme.
Der große Vorteil liegt in der Freiheit auf der Frontend Seite. Sie können eine Landingpage in Next.js, eine mobile App in React Native und eine Inhouse Bestellstation mit Vue bauen. Alle sprechen mit demselben Shopware 6 System. Das Backend bleibt dabei Ihr Single Source of Truth für Commerce Daten.
Wenn Sie die Grundlagen von Headless E Commerce noch einmal in Ruhe nachlesen möchten, hilft ein neutraler Überblick wie der Grundlagenartikel zu Headless E Commerce. Damit sortieren Sie gut im Kopf, was Headless bei Architektur und Kanälen bedeutet.
Shopware Headless: die Architektur von Shopware 6 im Überblick
Shopware 6 folgt einem API first Ansatz. Fast alles, was Sie im Admin machen, können Sie auch über eine API erledigen. Für Headless relevant sind zwei große Bereiche. Die Store API und die Admin API. Beide sprechen HTTP und JSON. Sie haben aber unterschiedliche Aufgaben und Zielgruppen.
Store API – Ihre Quelle für alle Shopdaten im Frontend
Die Store API liefert Ihnen das, was Ihr Kundenerlebnis braucht. Kategoriestrukturen, Produktlisten, Produktdetails, Suchergebnisse, Warenkorb, Kundenkonto und Checkout. Sie nutzen diese API direkt aus Ihrem Frontend Framework. Sie bauen damit klassische Seiten wie Kategorie, Produkt, Suche, aber auch personalisierte Startseiten und dynamische Widgets.
Wichtig ist hier, dass Sie Ihre Aufrufe klar strukturieren. Sie brauchen eine zentrale Schicht im Frontend, die alle Store API Calls kapselt. Keine wilden Fetch Aufrufe in jeder Komponente. Stattdessen ein eigenes Modul für Produktdaten, eines für Kunden und eines für Cart und Checkout. So behalten Sie den Überblick, können Logging einbauen und später Caching ergänzen.
Admin API – die Schaltzentrale für Stammdaten und Integrationen
Die Admin API nutzen Sie eher im Backend Kontext. Sie steuert Produkte, Preise, Bestände, Kundendaten und Bestellungen aus externen Systemen. Typische Beispiele sind ERP Integrationen, PIM Anbindungen oder ein eigenes Backend Tool für Content Management. Die Admin API braucht meist eine gesonderte Authentifizierung mit Client Credential Flow.
Für Ihr Headless Frontend ist die Admin API indirekt wichtig. Sie sorgt dafür, dass Ihr Shopware 6 System immer aktuelle Daten hat. Sie sollten sie kennen, damit Sie verstehen, wie Produkte und Inhalte ins System kommen und warum bestimmte Felder erscheinen, wie sie erscheinen.

Headless shopware – E-News für ambitionierte Entwickler – lesen Sie sich fit – 🛒Headless Commerce mit Shopware 6 – wie Sie Frontend Framework und API-Shop sauber verbinden⚙️
Shopware Frontend: das richtige Framework auswählen
Für Headless Commerce mit Shopware 6 landen viele Teams bei Vue oder React. Es gibt Shopware PWA Ansätze, Starter Templates und Beispielprojekte. Trotzdem sollten Sie sich nicht nur von Hype oder Lieblingsframework leiten lassen. Denken Sie zuerst an Ihr Team, Ihre Wartung und die Systeme darum herum.
Typische Optionen sind ein klassisches SPA oder eine SSR Variante mit Next.js oder Nuxt. Für E Commerce mag ich SSR plus Hydration, weil Sie bessere Kontrolle über Performance und SEO bekommen. Ihre Seiten können serverseitig gerendert werden und sind trotzdem interaktiv wie eine Single Page App.
Ganz wichtig ist ein responsives, mobile first Design. Nutzerinnen kaufen unterwegs. Die meisten greifen zuerst zum Handy, nicht zum Desktop. Ihr Headless Frontend sollte von Anfang an auf kleine Screens ausgelegt sein. Navigation, Filter, Suche und Checkout müssen auf dem Smartphone angenehm laufen. Desktop ist danach fast ein Bonus.
Vorbereitung in Shopware 6: Integrationen und API Zugänge
Bevor Sie Ihr Frontend Framework mit Shopware verbinden, richten Sie im Shop die API Zugänge sauber ein. In Shopware 6 finden Sie im Admin Bereich unter Einstellungen und System den Punkt Integrationen. Dort legen Sie eigene API Clients an, vergeben Schlüssel und definieren Rechte. So trennen Sie klar, welche Anwendung worauf zugreifen darf.
Für ein Kundenfrontend brauchen Sie in der Regel Zugriff auf Sales Channel, Produkte, Kategorien, Preise und Medien. Für ein internes Tool können andere Rechte nötig sein. Legen Sie lieber mehrere Integrationen an und geben Sie jeder nur das, was sie wirklich braucht. So bleibt Ihr System schlank und Sie reduzieren Risiken.
Einen guten Einstieg in die API Konzepte und Integrationen liefert die offizielle Shopware Dokumentation. Dort finden Sie auch Hinweise zur Einrichtung von Integrationen und zur Arbeit mit der API im Alltag.
Welche Shopware-API brauchen Sie: Store API oder Admin API?
Bevor die erste Zeile Code entsteht, lohnt eine Minute für diese Frage. Shopware 6 stellt zwei getrennte Schnittstellen bereit, und die Wahl entscheidet über Authentifizierung, Rechte und darüber, was überhaupt möglich ist. Beide sind REST-APIs und sprechen JSON — wenn Sie also nach der Shopware REST API suchen, meinen Sie eine von diesen beiden.
Die Store API ist die öffentliche Seite. Sie bedient genau das, was ein Storefront braucht: Kategorien, Produkte, Suche, Warenkorb, Checkout, Kundenkonto. Sie ist an einen Verkaufskanal gebunden und authentifiziert sich über dessen Zugriffsschlüssel. Für ein eigenes Frontend ist sie in aller Regel die richtige Wahl — sie ist auf Lesezugriffe und Kundensitzungen ausgelegt und liefert bereits fertig aufbereitete Daten.
Die Admin API ist die Rückseite. Sie erreicht praktisch den gesamten Datenbestand und darf schreiben — Artikel anlegen, Bestände setzen, Bestellungen ändern. Sie authentifiziert sich über eine Integration mit Zugangs-ID und Sicherheitsschlüssel (OAuth 2.0, Client Credentials). Für Anbindungen an eine Warenwirtschaft oder ein ERP führt kein Weg an ihr vorbei, für ein Frontend hat sie im Browser nichts verloren.
Die kurze Faustregel: Was der Kunde sieht, kommt aus der Store API. Was das Backoffice ändert, geht über die Admin API. Wer beides vermischt, baut sich entweder ein Rechteproblem oder eine Sicherheitslücke. Und wer für Massenschreibvorgänge die Admin API einzeln aufruft, wartet lange — dafür gibt es den Sync-Endpunkt, der viele Datensätze in einem Request entgegennimmt.
Ihr erster Request: von Access Token zur Produktliste
Der Einstieg in ein Headless Frontend läuft meistens über drei Schritte. Sie richten den API Zugang ein, testen erste Requests mit einem Tool wie Insomnia oder Postman und übertragen diese Calls danach ins Frontend Framework. Nehmen Sie sich Zeit für diesen Teil. Wenn Sie hier sauber arbeiten, sparen Sie sich später viele Stunden Fehlersuche.
Im einfachsten Fall holen Sie sich zuerst einen Access Token für die Store API Ihres Sales Channels. Danach rufen Sie eine Produktliste für eine Kategorie ab. Im Frontend bauen Sie sich darauf eine erste Produktübersicht. Sobald die läuft, können Sie Pagination, Filter und Sortierungen ergänzen. Schritt für Schritt, nicht alles auf einmal.
// stark vereinfachtes Beispiel für einen Fetch Call im Frontend
const response = await fetch('https://dein-shop.de/store-api/product', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'sw-access-key': 'DEIN_SALES_CHANNEL_KEY'
},
body: JSON.stringify({
filter: [
{ type: 'equals', field: 'product.active', value: true }
],
includes: {
product: ['id', 'name', 'cover', 'calculatedPrice']
}
})
});
const data = await response.json();
Sie sehen, dass Sie Filter, Includes und weitere Parameter angeben können. So steuern Sie, welche Daten Sie erhalten und wie groß Ihre Payload wird. Für Performance und Übersicht ist das sehr wichtig. Sie sollten nur Daten abrufen, die das Frontend wirklich nutzt.
API Layer im Frontend sauber strukturieren
Wenn Sie mit Headless Commerce arbeiten, sollten Sie Ihre API Calls im Frontend konsequent kapseln. Erstellen Sie einen eigenen Service Layer für Shopware. Dieser Layer enthält nur Funktionen wie getProducts, getProductById, search, addToCart, updateCart oder placeOrder. Komponenten greifen nicht direkt auf Fetch oder Axios zu, sondern immer über diese Service Funktionen.
So können Sie Authentifizierung, Fehlerbehandlung, Logging und Caching zentral kontrollieren. Wenn sich Endpunkte ändern oder neue Parameter dazu kommen, müssen Sie nur an einer Stelle anpassen. Ihre Komponenten bleiben schlank und konzentrieren sich auf Rendering und User Interaktionen. Das macht das Projekt robuster und besser wartbar.
Performance im Headless Setup optimieren
Headless Commerce gibt Ihnen viel Gestaltungsspielraum. Gleichzeitig sind Sie stärker selbst für Performance verantwortlich. Shopware 6 liefert Ihnen eine gut strukturierte API. Wie schnell sich die Seiten anfühlen, hängt aber zu einem großen Teil von Ihrem Frontend ab. Sie sollten von Beginn an auf Ladezeit, Renderpfad und Datenmenge achten.
Nutzen Sie Caching auf mehreren Ebenen. Browser Cache, Framework Cache und ein API Cache. Für Produkte und Kategorien können Sie häufig genutzte Daten im Frontend vorhalten und nur bei Bedarf aktualisieren. Nutzen Sie Lazy Loading für Bilder und Teile der Seite, die erst später relevant sind. Bauen Sie Skeleton States ein, damit Nutzerinnen sehen, dass gerade etwas passiert.
Ein Monitoring Werkzeug hilft Ihnen zusätzlich. Messen Sie Time to First Byte, Largest Contentful Paint und die wichtigsten Core Web Vitals. Wenn Sie hier regelmäßig drauf schauen, erkennen Sie früh, wann ein neues Feature Ihre Seite ausbremst. Dann können Sie nachjustieren, bevor Ihre Conversion leidet.
Saubere Fehlerbehandlung und Debugging Ihrer API Calls
Eine Headless Architektur ohne gute Fehlerbehandlung fühlt sich für Nutzerinnen schnell kaputt an. Sie sollten jedem API Call eine klare Strategie für Fehlermeldungen geben. Aus Frontend Sicht gibt es grob drei Kategorien. Technische Fehler, wie Netzwerkprobleme oder Timeouts. Fachliche Fehler, wie ungültige Voucher Codes. Und unerwartete Systemfehler im Shop.
Für jede Kategorie brauchen Sie eigene Antworten im UI. Ein technischer Fehler kann eine kurze Info mit einem Retry Button sein. Fachliche Fehler brauchen eine klare Erklärung, was schiefgelaufen ist und wie der Nutzer es korrigieren kann. Systemfehler sollten Sie loggen und, wenn möglich, zentral melden. So kann das Team schnell reagieren.
Loggen Sie sowohl Request als auch Response in einer Umgebung, auf die Sie Zugriff haben. Nutzen Sie dabei keine sensiblen Daten wie Klartext Passwörter oder komplette Kreditkarteninformationen. Konzentrieren Sie sich auf Endpunkte, Status Codes und relevante IDs. So können Sie Probleme gezielt nachstellen und beheben.
Typische Stolperfallen bei Headless Commerce mit Shopware 6
Viele Probleme in Headless Projekten drehen sich weniger um Code und mehr um Abstimmung. Die einen bauen am Frontend, die anderen am ERP oder am PIM. Shopware 6 sitzt in der Mitte. Wenn Sie hier keine klare API Verantwortung und saubere Schnittstellenbeschreibungen haben, wird es unübersichtlich. Sorgen Sie deshalb für ein gemeinsames API Dokument und feste Zuständigkeiten.
Ein anderer Klassiker ist eine übertriebene Menge an Requests. Jede Produktkarte lädt noch einmal Details, Bilder und Preise einzeln. Dasselbe gilt für Navigation und Filter. Sie sollten immer prüfen, welche Informationen Sie in einem Call bündeln können. Nutzen Sie Includes und Suchendpunkte. Machen Sie sich früh Gedanken über Aggregationen, Facetten und das Design Ihrer Listen.
Eine letzte Falle ist die Vernachlässigung von SEO. Nur weil Ihr Frontend Headless ist, darf es nicht blind für Suchmaschinen werden. Nutzen Sie Server Side Rendering oder Static Site Generation, bauen Sie sauber strukturierte Überschriften, Meta Tags und gut lesbare URLs. Halten Sie Content und Commerce getrennt, aber koordiniert. Gerade Blog, Ratgeber und Produktwelt sollten gemeinsam gedacht werden.
Praxisideen: Was Sie mit Headless und Shopware 6 umsetzen können
Mit einem Headless Setup auf Basis von Shopware 6 können Sie weit mehr bauen als eine klassische Shopfront. Sie können eine Produktberatung für Tablets im Store entwickeln, einen Konfigurator für komplexe Produkte oder eine Community Plattform mit direkter Anbindung an Warenkorb und Checkout. Alles greift dabei auf dieselben Shopware Daten zu.
Spannend wird es, wenn Sie personalisierte Startseiten, dynamische Kampagnenbereiche und kanalübergreifende Inhalte kombinieren. Nutzerinnen sehen dann auf der Startseite Produkte, die zu ihrem Verhalten passen. Gleichzeitig können Sie im Hintergrund Tests fahren und Varianten ausprobieren. So entsteht eine kontinuierlich verbesserte Customer Experience, die trotzdem zentral an einem System hängt.
Wenn Sie mögen, können Sie sich zusätzlich von einem Entwicklerguide inspirieren lassen, etwa durch einen deutschen Shopware API Guide für Entwickler. So sehen Sie, wie andere Teams die Schnittstellen modellieren und in ihre Architektur integrieren.
Weiterführend zu Shopware 6:






















{% endif %}
{% if title and title != "" %}
{{ title }}
{% endif %}
{% if excerpt and excerpt != "" %}