Shopware Headless: Composable Frontends und Store API

Headless klingt nach der Zukunft des E-Commerce. Und für bestimmte Vorhaben ist es das auch. Aber “headless” ist kein Schalter, den du einfach umlegt. Es ist eine Architekturentscheidung, die das gesamte Projekt beeinflusst, vom ersten Sprint bis zur laufenden Wartung. Dieser Artikel zeigt, was Shopwares Headless-Ansatz konkret bedeutet, wie die Store API funktioniert und wann der Aufwand wirklich gerechtfertigt ist.

Was “Headless” bei Shopware bedeutet

Im klassischen Betrieb liefert Shopware ein vollständiges Storefront-Rendering auf dem Server. Twig-Templates, Blöcke, Controller, alles aus einem Guss. Bei einem Storefront-Aufbau nach diesem Prinzip hat das klare Vorteile: schnelle Projektstarts, geringes Risiko, viele fertige Plugins.

Headless dreht das Modell um. Das Backend bleibt Shopware, aber das Frontend wird vollständig von Shopware entkoppelt. Statt Twig-Templates baut dein Entwicklerteam eine eigenständige Anwendung, die sich per API mit dem Shop-Backend verbindet. Das kann eine Vue.js-App mit Nuxt sein, ein React-Frontend, eine native Mobile-App oder eine statisch generierte Website.

Shopware unterstützt diesen Ansatz aktiv mit der Store API und dem offiziellen Toolkit “Composable Frontends”.

Die Store API: der Kern jeder Headless-Integration

Die Store API ist Shopwares öffentliche REST-Schnittstelle für alle kundenrelevanten Operationen. Sie deckt ab:

• Produktdaten, Kategorien, Suchergebnisse
• Warenkorb, Checkout, Bestellabschluss
• Kundenkonto, Adressen, Bestellhistorie
• CMS-Inhalte (Erlebniswelten) als strukturierte JSON-Daten
• Zahlungsarten, Versandmethoden, Steuern

Die Authentifizierung läuft über einen Sales-Channel-spezifischen Access Key. Für jede Headless-Storefront richtest du einen eigenen Sales Channel in der Administration ein und bekommst einen Token, der alle API-Anfragen autorisiert. Damit bleibt die Mandantentrennung sauber, auch wenn mehrere Frontends auf denselben Shop zugreifen.

Ein wichtiges Detail: Die Store API teilt dieselbe Business-Logik mit der klassischen Storefront. Preisberechnungen, Regelwerk, Rabattstaffeln, alles läuft durch den gleichen Shopware-Core. Du bekommst keine abgespeckte API, sondern denselben Funktionsumfang, nur anders verpackt.

Composable Frontends: Shopwares offizielles Headless-Toolkit

Seit einigen Jahren pflegt Shopware ein eigenes Open-Source-Framework für Headless-Storefronts. Die Composable Frontends basieren auf Vue.js 3 und Nuxt 3 und liefern eine Demo-Implementierung, die alle wesentlichen Shop-Funktionen abdeckt: Kategorieseiten, Produktdetail, Warenkorb, Checkout, Konto.

Darunter liegt eine TypeScript-Bibliothek (@shopware/composables), die sich unabhängig vom Vue-Ökosystem einsetzen lässt. In der Praxis bedeutet das: Wer lieber React oder SvelteKit nutzt, kann die API-Client-Logik übernehmen und das UI-Framework frei wählen.

Was du bei Composable Frontends bekommst:

• Typsichere API-Clients für alle Store-API-Endpunkte
• Composables für Warenkorb, Suche, Filter, Checkout
• SSR und SSG out of the box via Nuxt
• Aktive Pflege durch das Shopware-Kernteam

Was du selbst bauen musst:

• Das UI von Grund auf, oder als Anpassung der Demo-Implementierung
• Plugin-Kompatibilität, sofern Plugins Storefront-Templates mitbringen
• CMS-Anbindung, wenn du Erlebniswelten nutzen willst

Wann Headless wirklich sinnvoll ist

Ehrlich gesagt: Für die meisten mittelständischen Shops ist Headless nicht notwendig und erzeugt unnötigen Aufwand. Die klassische Shopware Storefront ist schnell, gut pflegbar und mit den richtigen Theme- und Templating-Techniken weitgehend frei gestaltbar.

Headless lohnt sich, wenn mindestens eines dieser Kriterien zutrifft:

• Du betreibst mehrere Frontends auf einem Backend (App, Web, Kiosk, POS)
• Du hast extreme Performance-Anforderungen, für die SSG oder Edge-Rendering entscheidend sind
• Du willst ein Framework nutzen, das Shopware-Twig nicht bietet (z.B. React-spezifische Komponentenbibliotheken)
• Du baust ein stark individualisiertes UI, das sich mit Twig-Overrides nicht mehr wartbar abbilden lässt
• Dein Team hat starke JavaScript-Expertise, aber wenig Twig-Erfahrung

In allen anderen Fällen solltest du die Shopware Storefront nutzen und nur bei konkreten Engpässen nachschärfen. Die Performance lässt sich mit gezielter Optimierung meistens ohne Architekturwechsel deutlich verbessern.

Technische Herausforderungen, die gern unterschätzt werden

Headless klingt clean. Die Realität ist komplexer. Drei Punkte, die in der Praxis regelmäßig Mehraufwand erzeugen:

Plugin-Kompatibilität. Shopware-Plugins, die eigene Storefront-Templates, JavaScript oder Twig-Blocks mitbringen, funktionieren in einem Headless-Setup nicht einfach so. Du musst für jede relevante Plugin-Funktionalität eine eigene API-Anbindung oder einen eigenen UI-Block bauen. Das betrifft Produktkonfiguratoren, Bewertungstools, Custom-Checkout-Erweiterungen und viele andere Erweiterungen aus dem Plugin-Ökosystem.

CMS und Erlebniswelten. Shopwares Erlebniswelten liefern ihre Inhalte über die Store API als strukturierte JSON-Blöcke. Für einfache Textblöcke ist das handhabbar. Sobald du komplexe Layout-Blöcke, Sliders oder externe Komponenten in den Erlebniswelten nutzt, wird das Rendering im Headless-Frontend deutlich aufwändiger.

Deployment und Caching. Eine klassische Shopware-Installation hat einen relativ klaren Caching-Stack: HTTP-Cache, optionales Redis, optionaler Varnish. Im Headless-Setup kommt eine zweite Infrastruktur-Ebene hinzu. Dein Nuxt-Frontend braucht eigenes Hosting, ein eigenes CDN, eigene Cache-Invalidierungs-Logik. Wer beides nicht sauber aufeinander abstimmt, handelt sich Cache-Inkonsistenzen ein.

Wenn du individuelle Schnittstellenlösungen oder komplexe API-Architekturen planst, hilft ein Blick auf unsere Leistungen rund um individuelle Softwareentwicklung, um den Scope realistisch einzuschätzen.

Headless im B2B-Kontext

Im B2B-Bereich gibt es besondere Überlegungen. Shopwares B2B-Funktionen, Kundengruppen, individuelle Preise, Bestellfreigabe-Workflows, sind teilweise über die Store API zugänglich, aber nicht vollständig. Einige B2B-Features, insbesondere aus den Shopware B2B Components, setzen auf Storefront-Rendering oder liefern nur eingeschränkte API-Unterstützung. Vor einem Headless-Projekt im B2B-Umfeld lohnt sich eine genaue Feature-Map, die zeigt, welche Funktionen über die API wirklich verfügbar sind und was du selbst bauen musst.

Häufige Fragen

Kann ich Headless und klassische Storefront gleichzeitig betreiben?

Ja. Shopware erlaubt mehrere Sales Channels parallel. Du kannst einen Sales Channel für die klassische Storefront betreiben und einen weiteren als API-Kanal für dein Headless-Frontend nutzen. Das ermöglicht eine schrittweise Migration: Du startest mit einzelnen Seiten im Headless-Frontend und hältst die Storefront als Fallback aufrecht.

Funktioniert das Shopware-Admin-Backend genauso wie bei klassischen Setups?

Vollständig. Der Shopware-Admin berührt das Frontend nicht. Produkte, Kategorien, Bestellungen, CMS-Inhalte, alles wird wie gewohnt im Backend gepflegt. Das Headless-Frontend holt sich diese Daten über die Store API und rendert sie eigenständig. Für das Redaktionsteam ändert sich am Admin-Workflow nichts.

Wie aufwändig ist die Pflege eines Headless-Setups langfristig?

Deutlich aufwändiger als eine klassische Storefront. Du pflegst zwei technische Stacks: das Shopware-Backend (Updates, Plugins, Konfiguration) und dein Frontend-Framework (Node.js, Nuxt, Abhängigkeiten, Deployment). Jedes Shopware-Update, das die Store API verändert, muss im Frontend nachgezogen werden. Das ist machbar, aber es braucht klare Verantwortlichkeiten und ein eingespieltes Deployment-Setup.

Für welche Editionstufen ist Headless verfügbar?

Die Store API ist in allen Shopware-Editionen verfügbar, auch in der Einstiegsstufe Rise. Die Composable Frontends als Open-Source-Framework sind ebenfalls editionsunabhängig nutzbar. Unterschiede gibt es bei API-Limits und bestimmten Enterprise-Features, die in den höheren Editionen (Evolve, Beyond) hinzukommen. Aktuelle Detailinfos zu Editionen und enthaltenen API-Funktionen ändert Shopware regelmäßig, also direkt auf der Shopware-Website prüfen.

Einschätzung für die Praxis

Headless mit Shopware ist technisch ausgereift. Die Store API ist stabil, gut dokumentiert und deckt die wesentlichen Commerce-Funktionen ab. Die Composable Frontends senken den Einstiegsaufwand erheblich. Aber der Betrieb eines Headless-Setups ist kein Selbstläufer und sollte nicht aus der “das klingt modern”-Motivation heraus gewählt werden.

Wenn du überlegst, ob ein Headless-Ansatz für deinen Shop passt, oder wenn du bereits ein Composable-Frontend betreibst und Unterstützung bei Architektur, API-Anbindung oder laufender Betreuung brauchst, sprich uns gerne an. Wir helfen dir, die Entscheidung auf Basis konkreter Anforderungen zu treffen, nicht auf Basis von Trendthemen.