Die Store API ist die kundenseitige Programmierschnittstelle (API) von Shopware 6. Sie stellt alle Daten und Funktionen bereit, die ein Onlineshop für den Einkauf braucht – Produkte, Kategorien, Preise, Warenkorb, Kundenkonto und Checkout – und liefert sie als strukturierte JSON-Antworten aus, statt sie in fertige HTML-Seiten zu rendern. Damit ist die Store API das technische Fundament jedes entkoppelten („headless") Shopware-Frontends: Sie trennt die eigentliche Commerce-Logik im Backend von der Darstellung im Frontend und macht es möglich, beliebige eigene Oberflächen vor das Shopware-Backend zu setzen.
Vereinfacht gesagt verwandelt die Store API ein Shopware-System in eine reine Commerce-Maschine, die auf Anfrage Daten ausliefert. Wer die klassische, mitgelieferte Storefront von Shopware nutzt, kommt mit der Store API nie direkt in Berührung – die Storefront spricht intern damit, der Händler sieht nichts davon. Erst wenn ein eigenes Frontend gebaut wird, etwa mit den offiziellen Shopware Frontends (Vue/Nuxt), mit React, Next.js oder einer nativen App, wird die Store API zum zentralen Werkzeug. Sie ist damit weniger ein einzelnes Feature als das Bindeglied einer ganzen Architektur-Entscheidung: Wer die Store API direkt anspricht, hat sich bewusst gegen das mitgelieferte Frontend und für volle Kontrolle über die Darstellung entschieden.
Was die Store API genau macht
Die Store API ist eine REST-API. Ein Frontend stellt HTTP-Anfragen an klar definierte Endpunkte und bekommt strukturierte Daten zurück. Anders als eine Seite, die der Server fertig zusammenbaut, liefert die Store API nur die Rohdaten – wie diese Daten dann dargestellt werden, entscheidet das Frontend selbst. Das ist der Kern des „Composable"- oder „Headless"-Gedankens: Backend und Frontend reden nur noch über diese Schnittstelle miteinander.
Typische Aufgaben, die über die Store API laufen:
- Produkte und Kategorien laden – Listing-Seiten, Produktdetails, Varianten, Eigenschaften und Medien.
- Suche und Filter – Volltextsuche, Filter-Aggregationen und Sortierung für die Produktlisten.
- Warenkorb verwalten – Artikel hinzufügen, Mengen ändern, Rabatte und Versandkosten berechnen.
- Kundenkonto – Registrierung, Login, Adressen, Bestellhistorie und Passwort-Verwaltung.
- Checkout – Zahlungs- und Versandarten wählen, Bestellung auslösen und bestätigen.
- Kontext – Sprache, Währung, Verkaufskanal und Kundengruppe, die jede Anfrage beeinflussen.
Wichtig ist die Abgrenzung zur Verwaltung: Die Store API ist nicht dafür da, Produkte anzulegen, Preise zu pflegen oder Bestellungen im Backend zu bearbeiten. Sie bildet ausschließlich die Sicht des Kunden ab. Für administrative Aufgaben gibt es eine eigene Schnittstelle, die Admin API.
Store API vs. Admin API
Shopware 6 stellt zwei getrennte APIs bereit, die häufig verwechselt werden. Die Unterscheidung ist für jedes Headless-Projekt grundlegend:
| Merkmal | Store API | Admin API |
|---|---|---|
| Perspektive | Kunde / Storefront | Verwaltung / Backoffice |
| Typischer Nutzer | Endkunde im Shop | Shop-Betreiber, ERP, PIM |
| Beispiel-Aktion | Produkt in den Warenkorb legen | Produkt anlegen oder Preis ändern |
| Authentifizierung | Access-Key des Verkaufskanals | OAuth-Token mit Admin-Rechten |
| Einsatz im Headless-Setup | Frontend / App | Datenpflege, Integrationen |
Faustregel: Alles, was ein Kunde im Shop tun darf, läuft über die Store API. Alles, was ein Mitarbeiter im Backend oder ein angebundenes System (ERP, PIM, CRM) tut, läuft über die Admin API. Ein entkoppeltes Frontend nutzt fast ausschließlich die Store API; die Admin API kommt bei Datenimporten und Systemintegrationen ins Spiel.
Wie die Store API im Headless-Setup funktioniert
In einem entkoppelten Aufbau läuft die Kommunikation zur Laufzeit ab: Jedes Mal, wenn ein Besucher eine Seite öffnet, holt das Frontend die nötigen Daten frisch über die Store API. Damit das funktioniert, braucht jede Anfrage zwei Dinge: einen Access-Key, der den Verkaufskanal identifiziert (übergeben im Header sw-access-key), und – sobald ein Warenkorb oder eine Kundensitzung im Spiel ist – einen Kontext-Token (Header sw-context-token), der die Sitzung über mehrere Anfragen hinweg zusammenhält.
Ein typischer Ablauf
Ein konkretes Beispiel macht das greifbar. Ein Kunde besucht eine Produktseite in einem headless gebauten Shopware-Shop, der die Shopware Frontends (Nuxt) einsetzt:
- Das Frontend fragt über
POST /store-api/product/{id}die Produktdaten ab und bekommt Titel, Beschreibung, Preis, Bilder und Verfügbarkeit als JSON zurück. - Der Kunde klickt „In den Warenkorb" – das Frontend ruft
POST /store-api/checkout/cart/line-itemauf und übergibt dabei densw-context-token, damit der Warenkorb der Sitzung zugeordnet bleibt. - Beim Bezahlen wählt der Kunde Versand- und Zahlungsart, das Frontend liest die verfügbaren Optionen über die Store API und löst die Bestellung mit
POST /store-api/checkout/orderaus.
Das Backend kümmert sich dabei um Preisberechnung, Lagerprüfung, Steuern und Regeln; das Frontend kümmert sich nur um Darstellung und Interaktion. Genau diese saubere Trennung erlaubt es, dasselbe Backend gleichzeitig für eine Website, eine native App und ein Kassenterminal im Laden zu nutzen – alle drei sprechen dieselbe Store API.
Die genauen Endpunkte, Parameter und Antwortschemata sind in der offiziellen Shopware-Entwicklerdokumentation beschrieben (siehe die Store-API-Dokumentation auf developer.shopware.com). Dort findet sich auch die vollständige OpenAPI-Referenz, mit der sich Clients automatisch generieren lassen.
Authentifizierung und Kontext
Die Store API ist bewusst offen gestaltet, weil sie öffentliche Shop-Daten ausliefert – Produktinformationen muss schließlich jeder Besucher sehen können. Geschützt wird sie über den Access-Key des Verkaufskanals, nicht über einen klassischen Login. Erst sobald es persönlich wird (Warenkorb, Kundenkonto, Bestellung), kommt der Kontext-Token hinzu. Dieser Token bildet die Sitzung ab: Er merkt sich, wer der Kunde ist, welche Sprache und Währung gewählt wurden und welche Kundengruppe gilt. Für Headless-Entwickler ist das Verständnis dieses Kontext-Mechanismus zentral, weil viele Fehler in der Praxis daher rühren, dass der sw-context-token zwischen Anfragen verloren geht und der Warenkorb dann „leer" erscheint.
Wer kein eigenes HTTP-Handling bauen möchte, nutzt den offiziellen API-Client aus dem Shopware-Frontends-Projekt. Dieser TypeScript-Client kapselt Authentifizierung, Kontext-Token-Verwaltung und die Request-/Response-Schemata und ist technologieneutral – er lässt sich also auch außerhalb von Vue oder Nuxt einsetzen, etwa in einer React- oder Next.js-Anwendung.
Wann die Store API für ein Projekt relevant wird
Die Store API ist nicht automatisch die bessere Wahl, nur weil sie „modern" klingt. Sie wird relevant, sobald ein Projekt das mitgelieferte Twig-Frontend von Shopware bewusst weglässt. Das ist eine Architektur-Entscheidung mit Folgen: Wer headless geht, verschiebt Arbeit, die die klassische Storefront fertig mitbringt (Templates, Theme-Editor, fertige Checkout-Oberfläche), in das eigene Entwicklungsteam. Ohne dieses Team steigt der Aufwand spürbar.
Sinnvoll ist der Einsatz der Store API vor allem in drei Fällen: wenn das Frontend selbst der entscheidende Wettbewerbsvorteil ist und die Möglichkeiten von Twig sprengt; wenn dieselben Commerce-Daten mehrere Kanäle (Website, native App, Point-of-Sale, Marktplatz) versorgen sollen; oder wenn ein eigenes Frontend-Team mit eigenem Release-Takt existiert. Für einen klassischen Standard-Shop, dessen Stärke im Sortiment, Service oder Preis liegt, bleibt die mitgelieferte Storefront in der Regel die wirtschaftlichere Wahl – sie spricht dieselbe Store API, nur eben fertig verpackt.
Die Store API steht in engem Zusammenhang mit Konzepten wie Headless Commerce, Composable Commerce und der MACH-Architektur. Sie ist der konkrete technische Baustein, der bei Shopware aus der abstrakten Idee „API-first" gelebte Praxis macht.
Store API, Caching und Performance
Ein häufiger Irrtum ist, dass ein Headless-Frontend automatisch schneller sei. Geschwindigkeit entsteht nicht durch die Entkopplung an sich, sondern durch sauberes Caching und durchdachtes Rendering. Weil die Store API bei jeder Anfrage frische Daten liefert, würde ein Frontend, das für jeden Seitenaufruf alle Endpunkte neu abfragt, das Backend unnötig belasten und langsam wirken. In der Praxis setzt man deshalb auf mehrere Ebenen: Shopware cached Store-API-Antworten serverseitig (HTTP-Cache), das Frontend hält statische oder selten wechselnde Inhalte über Mechanismen wie Incremental Static Regeneration oder einen CDN-Layer vor, und nur wirklich dynamische Anfragen – Warenkorb, Login, Checkout – gehen live an die API. Wer dieses Zusammenspiel ignoriert, baut ein technisch korrektes, aber langsames Headless-Frontend.
Eng damit verbunden ist das Thema Suchmaschinen-Sichtbarkeit. Da die Store API nur Daten und keine fertigen HTML-Seiten liefert, muss das Frontend serverseitiges Rendering (SSR) leisten, damit Suchmaschinen die Inhalte sehen. Ein rein im Browser zusammengebautes Frontend riskiert, dass der Crawler eine leere Seite vorfindet. Die Store API selbst ist dafür neutral – sie liefert die Daten; ob daraus eine crawlbare Seite wird, entscheidet die Rendering-Strategie des Frontends. Genau hier trennt sich in Projekten die Spreu vom Weizen: Die Store API gibt die Bausteine vor, die Performance- und SEO-Architektur muss das Team selbst verantworten, oft gemeinsam mit einer erfahrenen Agentur.
Häufige Fragen zur Store API
Ist die Store API kostenlos?
Ja. Die Store API ist Teil von Shopware 6, auch der Community Edition. Es fallen keine zusätzlichen Lizenzkosten allein für die Nutzung der Schnittstelle an. Kosten entstehen durch die Entwicklung und den Betrieb des eigenen Frontends, nicht durch die API selbst.
Was ist der Unterschied zwischen Store API und GraphQL?
Die Store API ist eine REST-API mit festen Endpunkten und JSON-Antworten. GraphQL ist ein alternativer Abfrage-Ansatz, bei dem der Client genau angibt, welche Felder er braucht. Shopware setzt für die kundenseitige Schnittstelle auf die REST-basierte Store API; eine offizielle GraphQL-Schnittstelle gehört nicht zum Standardumfang.
Brauche ich die Shopware Frontends, um die Store API zu nutzen?
Nein. Die Store API ist technologieneutral. Die Shopware Frontends (Vue/Nuxt) sind die offizielle, empfohlene Grundlage und liefern einen fertigen API-Client mit, aber jedes Frontend, das HTTP-Anfragen stellen kann, kann die Store API ansprechen – auch React, Next.js, native Apps oder andere Systeme.
Funktioniert die Store API auch für B2B-Shops?
Ja. Die Store API deckt auch B2B-Szenarien ab – etwa Firmenkonten, Angebotsprozesse und kundenspezifische Preise –, sofern die entsprechenden Shopware-Funktionen wie die B2B Components im Backend aktiv sind. Das Frontend liest diese Daten dann über dieselbe Schnittstelle wie im B2C-Fall, was die Store API auch für anspruchsvolle Großhandels- und Hersteller-Shops zu einer tragfähigen Grundlage macht.
Verliere ich bei der Store API meine Shopware-Plugins?
Teilweise. Backend-Plugins, die über das Backend wirken, funktionieren weiter. Plugins, die ihre Funktion über Storefront-Templates (Twig) ausliefern, greifen in einem entkoppelten Frontend nicht mehr und müssen im eigenen Frontend nachgebaut werden. Das ist einer der wichtigsten Punkte bei der Entscheidung für oder gegen ein headless Setup.