Store API oder Admin API für eine Integration
87 gegen 2.248 Endpunkte — aber die Zahl entscheidet nicht. Es entscheidet, wer fragt: ein Kunde im Browser oder ein System im Serverraum.
Die Frage kommt am Anfang jeder Integration, und die übliche Antwort — „die Admin API kann mehr" — ist zwar richtig und führt trotzdem regelmäßig zur falschen Wahl.
Die Zahlen, und warum sie nicht entscheiden
| Store API (Kern) | Admin API (Kern) | |
|---|---|---|
| Endpunkte in 6.7.13.1 | 87 | 2.248 |
| davon generierte CRUD | — | 2.000 |
| davon eigens geschrieben | 87 | 179 |
| in 6.6.10.6 | 81 | 2.050 |
Der Umfang unterscheidet sich um den Faktor 25. Trotzdem ist er das schwächste Entscheidungskriterium, denn die beiden APIs tun nicht dasselbe in unterschiedlichem Umfang — sie tun Verschiedenes.
Wie diese Zahlen zustande kommen und warum die Rohsummen irreführen, steht in Wie groß Shopwares API wirklich ist.
Der eigentliche Unterschied
Die Store API handelt im Namen eines Kunden. Jeder Aufruf läuft in einem Kontext: ein Verkaufskanal, eine Sprache, eine Währung, eine Kundengruppe, optional ein angemeldetes Konto. Preise kommen mit den Regeln dieses Kontexts, der Katalog mit den Sichtbarkeiten dieses Kanals.
Die Admin API handelt im Namen des Shops. Sie kennt keinen Verkaufskanal und keinen Warenkorb. Sie sieht Rohdaten: alle Produkte, alle Preise, alle Bestellungen — ohne die Aufbereitung, die ein Kunde bekommt.
Daraus folgt fast alles andere.
Was die Store API tatsächlich abdeckt
Die 87 Endpunkte verteilen sich auf erkennbare Aufgaben:
| Bereich | Endpunkte |
|---|---|
| Konto und Adressen | 22 |
| Checkout und Warenkorb | 8 |
| Produkt, Listing, Suche | 10 |
| Bestellungen des Kunden | 4 |
| Kontext, Sprache, Währung, Land | 7 |
| Newsletter und Kontaktformular | 4 |
| Navigation, Kategorie, CMS, Landingpage | 5 |
| Zahlung und Versand | 5 |
| Rest (Medien, SEO-URL, Dokument, Cookies, Widerruf …) | 22 |
Das ist ein vollständiger Shop — und nichts darüber hinaus. Es gibt keinen Endpunkt, um ein Produkt anzulegen, einen Preis zu ändern oder eine fremde Bestellung zu lesen. Das ist kein Mangel, sondern die Abgrenzung.
Die Sicherheitsfrage, die oft schiefgeht
Der Zugangsschlüssel der Store API steht im Quelltext jeder Storefront. Er ist öffentlich und muss es sein — er identifiziert den Verkaufskanal, er berechtigt nicht.
Ein Admin-Token ist das genaue Gegenteil: Es berechtigt zu allem, wozu die hinterlegte Rolle berechtigt. Es gehört in einen Serverprozess und niemals in etwas, das ein Browser ausliefert.
Der häufigste Fehler in Headless-Projekten ist deshalb nicht die Wahl der API, sondern ein Admin-Token in einer Anwendung, die im Browser läuft — oder in einem Frontend-Framework, dessen Server- und Clientteil nicht sauber getrennt sind.
Die Entscheidung
| Frage | Antwort |
|---|---|
| Handelt der Aufrufer im Namen eines Kunden? | Store API |
| Handelt er im Namen des Shops? | Admin API |
| Soll ein Browser direkt aufrufen? | nur Store API — ein Admin-Token darf dort nicht hin |
| Warenwirtschaft, PIM, ERP | Admin API |
| Eigenes Frontend, App, Kiosk | Store API, Hintergrunddienste daneben mit der Admin API |
| Preise wie der Kunde sie sieht | Store API — die Regeln greifen nur dort |
| Preise wie sie gepflegt sind | Admin API |
| Bestellungen eines Kunden | Store API |
| Bestellungen aller Kunden | Admin API |
| Daten schreiben, die kein Kunde schreiben darf | Admin API |
Die Zeile mit den Preisen wird am häufigsten übersehen. Wer über die Admin API Preise ausliest und im eigenen Frontend anzeigt, zeigt den gepflegten Preis — nicht den, der für diesen Kunden gilt. Welche Preisregel greift und warum, steht in Preisregeln in Shopware: welche gewinnt.
Was wir in Projekten zuerst klären
- Wer ist der Aufrufer? Ein Mensch mit Konto oder ein System ohne.
- Wo läuft der Code? Alles, was ein Browser ausliefert, ist öffentlich.
- Braucht es beides? Bei Headless fast immer — dann getrennte Zugänge, getrennte Rechte, getrennte Protokolle.
- Reicht die Store API für den Fall? Die 87 Endpunkte sind eine überschaubare Liste. Sie einmal durchzugehen dauert eine halbe Stunde und erspart eine Fehlentscheidung.
Punkt 4 ist der, den niemand macht — und der am zuverlässigsten wirkt.
Grenzen dieser Einordnung
Gezählt sind Endpunkte, nicht Fähigkeiten. Ob die 87 für Ihren konkreten Headless-Fall reichen, beantwortet keine Zählung — das ist ein Fähigkeitsvergleich je Vorgang und eine eigene Untersuchung, die wir bewusst offen lassen, statt sie zu schätzen.
Ebenso nicht Gegenstand: Antwortzeiten, Ratenbegrenzungen und die Frage, wie sich die APIs unter Last verhalten.
Wenn aus der Entscheidung eine Umsetzung wird, gehört das zu App- und Plugin-Entwicklung.
Häufige Fragen
- Kann ich mit der Store API Bestellungen auslesen?
- Nur die des angemeldeten Kunden. Die Store API arbeitet immer im Kontext eines Kundenkontos; eine Liste aller Bestellungen gibt es dort nicht.
- Ist der Store-API-Zugangsschlüssel geheim?
- Nein. Er steht im Quelltext jeder Storefront und identifiziert den Verkaufskanal, er berechtigt nicht. Ein Admin-Token ist das Gegenteil und gehört niemals in ein Frontend.
- Welche API nimmt eine Warenwirtschaft?
- Die Admin API. Sie arbeitet im Namen des Shops, nicht eines Kunden, und braucht Zugriff auf Bestände, Preise und Bestellungen unabhängig von einem Login.
- Kann ich beide kombinieren?
- Ja, und das ist bei Headless üblich: Das Frontend spricht die Store API, ein Hintergrunddienst die Admin API. Wichtig ist nur, dass die Zugangsdaten getrennt bleiben.