Shopify Next Generation Events: granulare Webhooks mit GraphQL

Das Problem klassischer Shopify-Webhooks

Wer eine ERP- oder PIM-Integration auf Shopify aufgebaut hat, kennt das Problem: Sobald ein Produkt aktualisiert wird, feuert der Webhook den kompletten Payload – selbst wenn sich nur ein Tag oder ein für das empfangende System irrelevantes Metafeld geändert hat.

Das erzeugt drei konkrete Ineffizienzen:

• Hohes Volumen nicht verwertbarer Deliveries, die Netzwerk- und Verarbeitungsressourcen binden
• Strukturelles Over-Fetching, da bei jedem Event unnötige Felder übertragen werden
• Applikationsseitige Diff-Logik, um herauszufinden, was sich gegenüber dem vorherigen Zustand tatsächlich geändert hat

Die Next Generation Events, jetzt als Developer Preview in der Shopify Admin GraphQL API verfügbar, adressieren diese drei Probleme direkt.

Drei Dimensionen granularer Kontrolle

Das neue System führt Kontrolle auf drei unterschiedlichen Ebenen ein: was eine Delivery auslöst, was der Payload enthält und was sich geändert hat.

1. Field-level Triggers

Mit den Next Generation Events lässt sich eine Subscription auf einen spezifischen Pfad wie product.variants.price definieren. Eine so konfigurierte Subscription löst bei Änderungen am Titel, an Tags oder anderen Feldern nicht aus – sie wird ausschließlich aktiviert, wenn sich der Preis der Varianten ändert.

Damit werden fehlerhafte Deliveries strukturell eliminiert, ohne dass anwendungsseitige Filter erforderlich sind.

2. Individueller Payload via GraphQL-Query

Anstatt einen von Shopify fest vorgegebenen Payload zu empfangen, definiert man beim neuen System direkt die GraphQL-Query, die jede Delivery befüllt. Das Ergebnis: Jedes Event enthält exakt die Felder, die für die Verarbeitung benötigt werden – ohne überflüssige Daten und ohne zusätzlichen API-Aufruf zum Nachladen fehlender Informationen.

Für Integrationen, die heute dem Muster Webhook + anreichernder API-Call folgen, bedeutet das eine messbare Reduktion der Anfragen an die Shopify-API.

3. Das Feld fields_changed

Jede Delivery enthält nun ein Feld fields_changed mit der expliziten Liste der geänderten Pfade, inklusive vollständigem Pfad und Entitäts-ID. Damit wird jede Vergleichslogik mit einem vorherigen Zustand im Anwendungscode überflüssig.

Anstatt einen lokalen Snapshot der Entität vorzuhalten und bei jedem Event einen Diff zu berechnen, kann das empfangende System direkt ablesen, welche Felder sich geändert haben, und entsprechend reagieren.

query_filter: Nicht verwertbare Deliveries reduzieren

Ein weiterer Kontrollmechanismus ist der query_filter, der Deliveries anhand des aktuellen Zustands der Entität zum Zeitpunkt des Events filtert. Ein typisches Beispiel: Events nur für Produkte mit dem Status ACTIVE liefern und Entwürfe sowie archivierte Produkte ignorieren.

In Kombination mit Field-level Triggers ermöglicht der query_filter sehr präzise Subscriptions, die den Traffic zu den Empfangs-Endpunkten auf einen Bruchteil des aktuellen Volumens reduzieren.

Config as Code mit shopify.app.toml

Next-Generation-Events-Subscriptions werden direkt in der Datei shopify.app.toml konfiguriert, zusammen mit der restlichen Anwendungskonfiguration. Das bedeutet, die Event-Definition ist:

• Versionierbar im Projektrepository
• Reviewbar im Code-Review-Prozess
• Reproduzierbar in verschiedenen Umgebungen ohne manuelle Konfigurationen

Für Teams, die mehrere Umgebungen (Entwicklung, Staging, Produktion) verwalten oder GitOps-Praktiken einsetzen, eliminiert dieser Ansatz die Abhängigkeit von manuell gepflegten Konfigurationen im Shopify-Dashboard.

Praktische Auswirkungen für ERP- und PIM-Integrationen

Bei hochvolumigen Katalogen wirken sich diese Änderungen messbar auf Performance und Kosten aus:

• Weniger empfangene Deliveries dank präziser Trigger und query_filter
• Geringere durchschnittliche Payload-Größe durch individuelle GraphQL-Queries
• Wegfall nachgelagerter API-Calls zur Datenanreicherung
• Vereinfachter Anwendungscode dank fields_changed

Integrationen, die heute Tausende Events pro Tag mit geringer Verwertbarkeit verarbeiten, profitieren am stärksten von dieser Architektur.

Empfehlungen für den Einstieg

Das System befindet sich aktuell in der Developer Preview auf der unstable API von Shopify und unterstützt die Topics Product und Customer. Vor einer Einführung sollte man folgende Schritte beachten:

• Aktuellen Traffic analysieren: Webhooks mit hohem Volumen und geringem Payload-Nutzen identifizieren – das sind die Hauptkandidaten für eine Migration
• In der Preview testen: Die heute verfügbaren Topics Product und Customer nutzen, um das erwartete Verhalten zu validieren
• Diff-Logiken ersetzen: Bestehende Consumer anhand von fields_changed refaktorieren
• query_filter konfigurieren: Filterkriterien auf Basis des aktuellen Zustands definieren, um nicht verwertbare Deliveries zu eliminieren
• Migration planen: Die API liegt auf unstable und ist ohne Migrationsplan auf eine stabile Version nicht produktionstauglich

Wenn du Custom-Integrationen auf Shopify Plus aufbaust oder weiterentwickelst und die passende Architektur für dein Volumen und deine Anforderungen evaluieren möchtest, findest du weitere Informationen zu unseren Entwicklungsleistungen auf der Seite für Entwickler-Preise und Services.

Fazit

Die Next Generation Events sind nicht nur eine Performance-Verbesserung für Webhooks: Sie definieren das Integrationsmodell mit Shopify neu und verlagern die granulare Kontrolle auf die Seite der Entwickler. Wer ernsthafte Integrationen für hochvolumige Kataloge baut, sollte dieses Muster jetzt erkunden – bevor es Stable-Status erreicht und zum erwarteten Standard wird.