Shopify-Schnittstellen: welche es gibt und wie du sie sauber anbindest

Ein technischer Ueberblick ueber alle relevanten Shopify-Schnittstellen: die drei Kern-APIs, die Anbindung an JTL, Lexoffice, DATEV, Versand, Klaviyo und Marktplaetze, dazu Custom-App-Auth, Rate-Limits, sichere Webhooks und die Fehler, die du vermeiden solltest.

Warum Schnittstellen der eigentliche Hebel sind

Ein Shopify-Shop steht selten allein. Sobald du Bestellungen ins ERP schiebst, Rechnungen an die Buchhaltung uebergibst, Labels beim Versanddienstleister ziehst oder Kundendaten ins E-Mail-Marketing spielst, brauchst du Schnittstellen. Wer hier sauber plant, spart sich haendische Doppelerfassung, Fehlbuchungen und naechtliche Notfaelle, wenn ein Sync haengt.

Dieser Artikel gibt dir den Ueberblick, den du zum Entscheiden brauchst: welche APIs Shopify anbietet, wofuer jede gedacht ist, wie du dich authentifizierst, welche Grenzen (Rate-Limits) gelten und wie du Webhooks so verarbeitest, dass sie auch bei Lastspitzen zuverlaessig bleiben. Ausserdem ordnen wir die typischen Anbindungen (Warenwirtschaft, Buchhaltung, Versand, CRM, Marktplaetze) ein. Wenn du eine konkrete Umsetzung suchst, findest du sie unter /integrations/shopify/ sowie in unseren weiteren Shopify-Insights.

Die drei Kern-APIs: Storefront, Admin und Webhooks

Shopify trennt seine Schnittstellen nach Aufgabe. Du solltest wissen, welche du wofuer nimmst, sonst baust du gegen die falsche API an.

• Storefront API (GraphQL): fuer alles, was der Kunde sieht. Produktdaten, Warenkorb, Checkout-Start bei Headless-Setups (etwa Next.js oder Hydrogen). Zugriff ueber einen oeffentlichen Token im Header X-Shopify-Storefront-Access-Token. Sie ist bewusst leseoptimiert und kennt keine sensiblen Backoffice-Daten.
• Admin API: das Backoffice. Bestellungen, Produkte, Bestand, Kunden, Fulfillment, Rueckerstattungen. Endpunkt fuer GraphQL ist /admin/api/2025-01/graphql.json. Shopify hat GraphQL zur primaeren Admin-API gemacht und die REST-Admin-API auf Legacy-Status gesetzt, neue Produkt-Objekte gibt es teils nur noch ueber GraphQL. Fuer neue Anbindungen also GraphQL bevorzugen, REST nur, wo ein Endpunkt noch nicht migriert ist.
• Webhooks: Push statt Pull. Shopify meldet dir Ereignisse wie orders/create, orders/paid, products/update oder app/uninstalled aktiv an deinen Endpunkt. So musst du nicht im Sekundentakt pollen und bekommst Bestellungen nahe an Echtzeit.

Faustregel: Kunde sieht es, nimm Storefront. Du verarbeitest es intern, nimm Admin. Du willst ueber Aenderungen informiert werden, nimm Webhooks.

Auth: Custom App und Access Token statt Bastelloesung

Fuer die meisten DACH-Shops, die keine App im Shopify App Store veroeffentlichen wollen, ist die Custom App der richtige Weg. Du legst sie im Admin an unter Einstellungen > Apps und Vertriebskanaele > Apps entwickeln. Dort waehlst du die Berechtigungen (Scopes) und bekommst danach ein Admin-API-Token, optional zusaetzlich ein Storefront-Token.

Der Admin-Token wandert bei jedem Request in den Header X-Shopify-Access-Token. Vergib Scopes so eng wie moeglich: read_orders und write_fulfillments statt pauschal alles. Jeder ueberfluessige Schreib-Scope ist ein Risiko, falls das Token doch mal ausserhalb deiner Systeme landet.

• Token gehoert in einen Secret-Store (Umgebungsvariable, Vault, Cloudflare-Secret), nie ins Frontend und nie ins Git-Repo.
• API-Version im Endpunkt pinnen (Format YYYY-MM, z. B. 2025-01). Shopify veroeffentlicht quartalsweise, jede Version ist rund neun Monate stabil. Ohne Pinning brechen dir Felder weg, sobald Shopify die Default-Version dreht.
• Fuer oeffentliche Apps mit vielen Shops nimmst du stattdessen OAuth, das Prinzip mit Scopes und Token bleibt gleich.

Die wichtigsten Anbindungen im Ueberblick

Die meisten Projekte drehen sich um dieselben fuenf Kategorien. Fuer jede gibt es Fertigconnectoren und den Weg ueber eine eigene Custom App.

• Warenwirtschaft / ERP: Bei JTL-Wawi laeuft die Anbindung ueber den JTL-Connector fuer Shopify, der Artikel, Bestand und Bestellungen abgleicht. Groessere Haeuser binden SAP oder Microsoft Dynamics ueber Middleware an. Kernfrage immer: Wer ist fuehrendes System fuer Bestand und Preise, Shopify oder das ERP.
• Buchhaltung: Lexoffice (jetzt lexware office) hat eine offene API, Bestellungen laufen ueber Connectoren oder eigene Skripte als Belege ein. DATEV wird meist ueber Export oder Middleware (etwa evers oder Accountable-artige Bridges) bedient, weil der Steuerberater DATEV-Formate erwartet.
• Versand: Sendcloud, shipcloud oder direkt DHL setzen auf Shopify-Bestellungen auf, erzeugen Labels und melden Tracking-Nummern per Fulfillment zurueck an Shopify.
• CRM und E-Mail: Klaviyo und HubSpot haben native Shopify-Integrationen, die Bestell- und Verhaltensdaten (etwa Placed Order) einspielen. Fuer Klaviyo ist das der Standardweg fuer Flows und Segmentierung.
• Marktplaetze: Ueber Shopify Marketplace Connect (frueher Codisto) oder Anbieter wie Channable spielst du Kataloge zu Amazon, eBay und Otto und holst Bestellungen zurueck.

Rate-Limits: rechne mit Grenzen, bevor du sie triffst

Shopify drosselt Anfragen, und zwar je API unterschiedlich. Wer beim ersten Vollimport ohne Bremse gegen die API laeuft, kassiert Fehler und unvollstaendige Daten.

• REST Admin nutzt ein Leaky-Bucket-Modell: rund 2 Anfragen pro Sekunde bei Standardplaenen, Eimergroesse 40, bei Shopify Plus hoeher. Ist der Eimer voll, kommt HTTP 429 mit dem Header Retry-After.
• GraphQL Admin rechnet nicht in Requests, sondern in Punkten pro Abfragekosten. Standard sind 1000 Punkte im Eimer, Wiederauffuellung 100 Punkte pro Sekunde (Plus doppelt). Jede Antwort liefert unter extensions.cost den throttleStatus, daran siehst du dein verbleibendes Budget.
• Storefront API wird pro IP begrenzt und ist grosszuegiger, aber nicht unendlich.

In der Praxis heisst das: 429 und throttleStatus auswerten, mit exponentiellem Backoff neu versuchen und bei Massenabgleichen die Bulk Operations der Admin-API nutzen, statt tausende Einzelabfragen zu feuern. Ein Vollimport von 20.000 Produkten gehoert in eine Bulk-Query, nicht in eine Schleife.

Webhooks richtig: HMAC pruefen und idempotent verarbeiten

Webhooks sind bequem, aber offen. Jeder, der deine Endpunkt-URL kennt, koennte gefaelschte Bestellungen schicken. Deshalb pruefst du jede Nachricht per HMAC-Signatur. Shopify signiert den Rohbody mit dem App-Secret und legt die Signatur in den Header X-Shopify-Hmac-Sha256.

Du berechnest selbst HMAC-SHA256(rawBody, appSecret), kodierst das Ergebnis als Base64 und vergleichst es zeitkonstant mit dem Header. Wichtig: den rohen Body verwenden, nicht das bereits geparste JSON, sonst stimmt die Signatur nie. Passt sie nicht, antwortest du mit 401 und verarbeitest nichts.

Der zweite Baustein ist Idempotenz. Shopify liefert bei jedem Zweifel erneut aus (bis zu 48 Stunden, viele Wiederholungen), du bekommst dasselbe Ereignis also mehrfach. Speichere die X-Shopify-Webhook-Id oder die Objekt-ID und verwirf Duplikate, sonst legst du eine Bestellung doppelt an. Konkret:

• Signatur pruefen, bevor du irgendetwas mit den Daten machst.
• Innerhalb von rund 5 Sekunden mit 200 antworten, sonst wertet Shopify es als Fehlschlag und wiederholt. Schwere Arbeit gehoert in eine Queue, nicht in den Request.
• Jede verarbeitete Webhook-ID persistieren, wiederkehrende IDs sofort mit 200 quittieren und ignorieren.

Typische Fehler und die Entscheidung, die du treffen musst

Die meisten kaputten Shopify-Anbindungen scheitern an denselben Punkten. Wenn du sie vorher kennst, sparst du dir die Nachtschichten.

• Keine API-Version gepinnt: Der Sync laeuft monatelang, dann dreht Shopify die Default-Version und Felder verschwinden. Immer explizit versionieren.
• Webhook ohne HMAC: funktioniert im Test, ist aber ein offenes Scheunentor. Signaturpruefung ist Pflicht, nicht Kuer.
• Nicht idempotent: doppelte Bestellungen und doppelte Rechnungen, weil Retries nicht abgefangen werden.
• Polling statt Webhooks: frisst dein Rate-Limit-Budget und ist trotzdem langsamer. Fuer Ereignisse Webhooks nehmen, Polling nur als Sicherheitsnetz.
• Zu breite Scopes: ein geleaktes Token mit vollem Schreibrecht ist ein anderer Schaden als eines mit read_orders.

Die Grundentscheidung lautet: Fertigconnector oder eigene Custom App. Ein Connector (Klaviyo, JTL, Sendcloud) ist schneller live und guenstig im Betrieb, solange dein Prozess in seine Logik passt. Eine eigene App lohnt, sobald du Sonderfaelle, eigenes Fehlerhandling oder mehrere Systeme in einem Fluss brauchst. Beide Wege nutzen dieselben APIs, dieselben Rate-Limits und dieselbe Webhook-Sicherheit, die du hier gelesen hast. Eine begleitete Umsetzung dieser Anbindungen findest du unter /integrations/shopify/.