Shopify API 2026: Admin, Storefront & GraphQL erklärt

Die Shopify API ist die technische Schnittstelle, über die dein Store mit externen Systemen kommuniziert. Ob ERP-Anbindung, eigene App oder Custom Frontend: Ohne API geht nichts davon. Ich entwickle selbst eine Shopify App (Boomerang Bounce Back App) und arbeite täglich mit der API. In diesem Artikel erkläre ich dir als Store-Owner und Entwickler, was wirklich relevant ist, was sich 2024 grundlegend geändert hat und warum die API für die meisten Store-Betreiber trotzdem keine direkte Rolle spielt.

Was ist die Shopify API?

Die Shopify API (Application Programming Interface) ist die standardisierte Schnittstelle, über die externe Software auf die Daten deines Shopify Stores zugreift. Jede App, die du installierst, jede ERP-Anbindung und jedes Custom Tool kommuniziert über diese Schnittstelle mit deinem Store. Die API liest Bestellungen aus, aktualisiert Lagerbestände, erstellt Produkte oder verarbeitet Kundendaten.

Stell dir die API wie eine Steckdose vor. Dein Store ist das Stromnetz. Und jede App, jedes externe System ist ein Gerät, das sich einsteckt. Die Steckdose sorgt dafür, dass alles nach einem einheitlichen Standard funktioniert.

Was viele Store-Owner nicht wissen: "Die Shopify API" gibt es eigentlich gar nicht als einzelnes Ding. Es ist ein ganzes Ökosystem aus mehreren spezialisierten APIs, die jeweils einen anderen Zweck erfüllen. Die Admin API kümmert sich um Backend-Daten, die Storefront API um das Frontend, Webhooks reagieren auf Events im Store. Welche du brauchst, hängt komplett von deinem Use Case ab.

Und ehrlich gesagt: Als Store-Owner kommst du mit der API meistens gar nicht direkt in Berührung. Die Apps in deinem Store erledigen das im Hintergrund. Die API wird erst dann zum Thema, wenn du etwas Individuelles brauchst, das keine App von der Stange abdeckt.

Die wichtigsten Shopify APIs im Überblick

Shopify bietet mehrere APIs an, die jeweils für unterschiedliche Aufgaben gedacht sind. Die Admin API (GraphQL) ist die zentrale Schnittstelle für alles, was im Backend passiert. Die Storefront API bedient Custom Frontends. Daneben gibt es Webhooks für Event-basierte Automatisierung, die Ajax API für Theme-Erweiterungen und Shopify Functions für serverseitige Checkout-Logik.

Hier die Kurzübersicht:

Admin API (GraphQL): Dein Hauptzugang zum Backend. Produkte erstellen, Bestellungen auslesen, Lagerbestände synchronisieren, Kunden verwalten. Seit Oktober 2024 ist GraphQL der offizielle Standard, REST ist deprecated.

Storefront API: Baut kundenseitige Erlebnisse. Custom Frontends, Mobile Apps, Headless Commerce. Greift nur auf öffentliche Daten zu, keine sensiblen Backend-Informationen.

Webhooks: Dein Store schickt automatisch Benachrichtigungen, wenn etwas passiert. Neue Bestellung, Produkt aktualisiert, Kunde registriert. Das Fulfillment-System deines Versanddienstleisters nutzt Webhooks, um sofort von neuen Bestellungen zu erfahren.

Ajax API: Eine leichtgewichtige API auf Theme-Ebene. Warenkorb aktualisieren, Produktvarianten laden, alles ohne Seiten-Reload. Nutzt du indirekt, wenn dein Theme dynamische Elemente hat.

Shopify Functions: Serverseitige Logik für Checkout-Anpassungen. Dynamische Rabatte, individuelle Versandkosten-Berechnung, Custom Payment Rules. Nur auf Shopify Plus verfügbar.

Admin API (GraphQL): Das Herzstück für Automatisierung

Die Admin API ist die API, mit der du als Entwickler oder über Middleware-Tools am häufigsten arbeitest. Sie gibt dir Zugriff auf praktisch alle Daten deines Stores: Produkte, Bestellungen, Kunden, Lagerbestände, Fulfillment, Metafields. Alles, was du im Shopify Admin manuell machen kannst, lässt sich über die Admin API auch programmatisch steuern.

Seit Oktober 2024 ist die REST Admin API offiziell deprecated. Shopify hat den Wechsel zu GraphQL als einzigem Standard vollzogen. Das war kein kleiner Schritt.

Ich habe diese Migration bei meiner eigenen App, der Boomerang Bounce Back App, selbst durchgemacht. Der Umstieg von REST auf GraphQL war nicht trivial. GraphQL denkt fundamental anders: Statt fester Endpunkte (GET /products.json) formulierst du Queries, die exakt die Felder zurückliefern, die du brauchst. Das ist effizienter, weil du nicht jedes Mal den kompletten Datensatz bekommst. Gleichzeitig ist die Lernkurve steiler, besonders wenn du vorher mit REST gearbeitet hast.

Ein konkretes Beispiel: Bei Boomerang frage ich pro API-Call nur die Felder ab, die ich tatsächlich brauche (Bestell-ID, Stornierungsgrund, Kunden-E-Mail). Mit REST hätte ich jedes Mal den gesamten Order-Datensatz bekommen, inklusive dutzender Felder die mich nicht interessieren. Bei einem Store mit 500+ Bestellungen pro Tag macht das einen spürbaren Unterschied bei der Performance und beim Verbrauch der Rate Limits.

Für deutsche Store-Owner ist die Admin API vor allem bei einem Thema relevant: ERP-Integration. Wenn du deinen Shopify Store mit Lexware, Sage oder einem SAP-System verbinden willst, läuft das über die Admin API. Bestellungen raus, Lagerbestände rein, Rechnungsdaten synchronisieren. Das ist der mit Abstand häufigste API-Use-Case, den ich bei DACH-Shops sehe.

Storefront API: Wenn Shopify nur noch das Backend ist

Die Storefront API ermöglicht es dir, ein komplett eigenes Frontend zu bauen, das unabhängig vom Shopify Theme läuft. Shopify liefert dann nur noch die Daten (Produkte, Preise, Warenkorb), während dein Custom Frontend die Darstellung übernimmt. Das Konzept heißt Headless Commerce.

Klingt auf dem Papier großartig. In der Praxis sehe ich Headless Commerce bei DACH-Shops unter einer Million Euro Jahresumsatz fast nie. Und wenn, dann meistens als Fehlentscheidung.

Der Grund ist simpel: Ein Headless Setup kostet 30.000 bis 80.000 Euro in der initialen Entwicklung, braucht laufende Wartung und macht Updates komplexer. Ein gut konfiguriertes Shopify Theme mit Dawn oder einem Premium-Theme deckt für 95 % der Shops alles ab.

Die Storefront API hat aber einen zweiten, weniger bekannten Use Case: Mobile Apps. Wenn du eine native iOS- oder Android-App für deinen Store bauen willst, ist die Storefront API der richtige Einstieg. Sie liefert alle kundenseitigen Daten (Produkte, Collections, Checkout) ohne Zugriff auf sensible Backend-Informationen.

App vs. API Entscheidungsmatrix: Wann brauchst du die API wirklich?

Das ist die Frage, die ich als App-Entwickler am häufigsten höre: "Brauche ich die API oder reicht eine App?" Die ehrliche Antwort: Für etwa 80 % der Store-Owner ist die API als direkter Kontaktpunkt komplett irrelevant. Nicht weil sie unwichtig wäre, sondern weil Apps die API-Arbeit im Hintergrund erledigen.

Ich habe aus meiner Praxis ein einfaches Entscheidungsframework entwickelt, das ich auch meinen Kunden bei HS Activa und in Beratungsgesprächen empfehle:

Kauf eine App aus dem App Store, wenn:

• Dein Problem ein Standardproblem ist (Abandoned Cart Recovery, Upselling, Reviews)
• Eine App mit guten Bewertungen existiert, die genau das tut
• Du keine Entwicklerressourcen hast oder brauchst

Nutze die API über Middleware (Make.com, Zapier), wenn:

• Du zwei Systeme verbinden willst (z. B. Shopify + Google Sheets, Shopify + CRM)
• Der Workflow nicht komplex ist
• Du kein Budget für einen Entwickler hast, aber technisches Grundverständnis mitbringst

Beauftrage einen Entwickler mit einer Custom API-Integration, wenn:

• Dein ERP-System keine fertige Shopify-App hat (häufig bei DATEV, älteren SAP-Installationen)
• Du individuelle Geschäftslogik brauchst, die keine Standard-App abdeckt
• Du mehrere Systeme in einem Flow verbinden musst (z. B. Shopify + ERP + Versanddienstleister + Buchhaltung)

Bau selbst mit der API, wenn:

• Du eine eigene Shopify App für den App Store entwickeln willst
• Du ein Entwickler bist und Custom Tools für deine Stores brauchst

Bei der Boomerang Bounce Back App habe ich mich bewusst für eine eigene App entschieden, weil keine bestehende Lösung das Problem so gelöst hat, wie ich es aus der Store-Betreiber-Perspektive für richtig halte. Der Entwicklungsprozess hat mir aber auch gezeigt: Der Aufwand für eine eigene API-Integration wird fast immer unterschätzt. Allein die Authentifizierung, das Error Handling und die Rate-Limit-Logik fressen Wochen an Entwicklungszeit.

Wie du den API-Zugang einrichtest

Wenn du die Shopify API nutzen willst, brauchst du einen Access Token. Den bekommst du über eine Custom App in deinem Shopify Admin. Der Prozess dauert etwa 5 Minuten, aber es gibt ein paar Punkte, die du beachten solltest.

Schritt 1: Custom App erstellen. Geh in deinem Shopify Admin auf "Einstellungen" → "Apps und Vertriebskanäle" → "Apps entwickeln". Aktiviere die App-Entwicklung, falls noch nicht geschehen, und erstelle eine neue App.

Schritt 2: API-Berechtigungen (Scopes) festlegen. Hier wählst du, auf welche Daten die App zugreifen darf. Mein Rat: Vergib nur die Berechtigungen, die du tatsächlich brauchst. Wenn du nur Bestellungen auslesen willst, brauchst du keinen Schreibzugriff auf Produkte. Das Prinzip der minimalen Berechtigung ist hier nicht optional, sondern Pflicht.

Schritt 3: Access Token generieren. Nach dem Speichern der Scopes kannst du den Admin API Access Token generieren. Diesen Token siehst du nur einmal. Kopiere ihn sofort und speichere ihn sicher.

Schritt 4: Erste Anfrage testen. Mit einem Tool wie Postman oder direkt per cURL kannst du deine erste GraphQL-Anfrage an https://dein-store.myshopify.com/admin/api/2026-01/graphql.json schicken. Wenn du eine Antwort mit Daten bekommst, funktioniert alles.

Ein Punkt zu den Rate Limits: Shopify begrenzt die Anzahl der API-Anfragen, die du pro Sekunde machen kannst. Im Basic-Plan sind es ca. 2 Anfragen pro Sekunde, bei Plus 4 pro Sekunde. Klingt nach viel, wird aber bei größeren Datenmengen schnell eng. Bei der Entwicklung von Boomerang war das Rate Limit eine der größten technischen Herausforderungen, besonders bei Stores mit zehntausenden Bestellungen. Du musst Retry-Logik einbauen, Anfragen staffeln und dein Query-Design optimieren.

Alle Details zu den aktuellen API-Versionen und Endpunkten findest du in der offiziellen Shopify API Dokumentation.

Shopify API im DACH-Markt: Was deutsche Store-Owner beachten müssen

Die Shopify API Dokumentation und die meisten Tutorials sind auf den US-Markt ausgerichtet. Im DACH-Raum gibt es aber spezifische Anforderungen, die du kennen solltest, wenn du mit der API arbeitest oder eine Integration planst.

ERP-Integration ist der Hauptgrund für API-Nutzung in DACH. In den USA nutzen die meisten Shops cloud-basierte Systeme, die native Shopify-Apps haben. In Deutschland, Österreich und der Schweiz laufen viele Unternehmen auf Lexware, Sage, DATEV oder älteren SAP-Installationen. Für diese Systeme gibt es oft keine fertige Shopify-App. Das bedeutet: Custom API-Integration über Middleware oder einen Entwickler.

Bei HS Activa haben wir genau diese Situation. Die Anbindung an unser Warenwirtschaftssystem lief über eine Custom Integration, weil es keine App gab, die unsere spezifischen Anforderungen abgedeckt hat: Bestellungen synchronisieren, Lagerbestände in Echtzeit abgleichen, Rechnungsdaten für die Buchhaltung exportieren. Das hat funktioniert, aber der initiale Aufwand lag bei mehreren Wochen Entwicklungszeit.

DSGVO und API-Zugriff. Jede API-Integration, die Kundendaten verarbeitet, muss DSGVO-konform sein. Das betrifft nicht nur den Token-Schutz (siehe oben), sondern auch die Frage: Wo werden die Daten gespeichert, die du über die API abrufst? Wenn du einen externen Dienst nutzt, der Daten auf US-Servern speichert, brauchst du einen Auftragsverarbeitungsvertrag und musst sicherstellen, dass die Übermittlung rechtlich abgesichert ist. Im Zweifel: Frag deinen Datenschutzbeauftragten, bevor du eine Integration live schaltest.

Steuerliche Besonderheiten. Deutschland hat mit dem gespaltenen Mehrwertsteuersatz (7 % und 19 %) eine Besonderheit, die in API-Integrationen korrekt abgebildet werden muss. Wenn du Bestelldaten über die API an dein Buchhaltungssystem übergibst, müssen die Steuersätze stimmen. Klingt banal, ist aber eine häufige Fehlerquelle, die ich bei DACH-Shops regelmäßig sehe.

Für eine vollständige Übersicht über die API-Endpunkte und aktuelle Änderungen empfehle ich den Shopify Developer Changelog.

Fazit