Wer Webhook-Subscriptions für ein eigenes Shopsystem, ein ERP-Anbindungsskript oder eine Middleware nutzt, sollte den Payload-Parser in dieser Woche prüfen. Der Anbieter aktualisiert ab sofort die Struktur von Events-Payloads, die Trigger-Syntax und die Delivery-Header. Klassische Webhook-Subscriptions bleiben unverändert – der Bruch trifft ausschließlich die Event-basierte Zustellung.
Warum bricht das Feld fields_changed bestehende Integrationen?
Der zentrale Eingriff betrifft genau ein Feld: fields_changed. Bisher lieferte es ein flaches Array von Pfaden. Künftig ist es ein Objekt mit drei separaten Arrays – added, updated und removed. Damit lässt sich auf Payload-Ebene unterscheiden, ob eine Ressource oder Beziehung neu angelegt, ein Wert geändert oder ein Eintrag gelöscht wurde.
Für Shopbetreiber mit produktivem Datenabgleich ist das kein Kosmetik-Update. Jede Middleware, die fields_changed als Liste einliest und über einen Index iteriert, wird nach dem Rollout ins Leere laufen oder falsche Werte schreiben. Besonders kritisch ist das im Lagerabgleich: Wer removed nicht auswertet, behält Produkte im Sortiment, die im PIM längst gelöscht sind. Wer added nicht trennt, überschreibt Neu-Anlagen mit Default-Werten aus dem Altbestand.
Der Anbieter liefert mit dem Objekt-Format eine semantische Information, die vorher nur über einen zweiten Request zu holen war. Das reduziert API-Last bei synchronen Shops, entlastet aber nur die, die das neue Format tatsächlich auswerten. Wer die alte Flachstruktur weiterverarbeitet, verliert diese Information ersatzlos.
Welche Shopsysteme sind betroffen?
Direkt betroffen sind alle, die Events-Subscriptions gegen das System fahren. Bei Shopify-Nutzern, die auf die Admin-API-Events setzen, sowie bei Shopware- und Adobe-Commerce-Setups mit eigener Event-Middleware ist der Check Pflicht. Reine Connector-Lösungen wie Shopify Flow oder Standard-WooCommerce-Setups ohne eigene Event-Verarbeitung dürften unberührt bleiben – der Anbieter stellt ausdrücklich klar, dass Classic Webhook-Subscriptions nicht angefasst werden.
Entwickler sollten drei Dinge prüfen: die Deserialisierung von fields_changed, die Trigger-Syntax in den Subscription-Definitionen und die Auswertung der Delivery-Header. Letztere ändern sich ebenfalls und betreffen Signaturen und Idempotenz-Prüfungen. Wer Retry-Logik auf Basis der Header gebaut hat, muss die Feldnamen abgleichen.
- Parser für
fields_changedauf Objekt mit drei Arrays umstellen - Trigger-Syntax in bestehenden Subscription-Definitionen gegenprüfen
- Delivery-Header-Auswertung für Signatur und Idempotenz aktualisieren
- Staging-Test mit realen Events vor dem Produktiv-Deploy
Wie schnell muss reagiert werden?
Die Änderung ist ab sofort aktiv. Wer Events im Produktivbetrieb verarbeitet, hat keine Übergangsfrist, sondern eine Fehlerperiode, die bereits läuft. Praktikabel ist ein zweistufiger Rollout: erst Logging umstellen und beide Strukturen parallel einlesen, dann den Alt-Pfad nach zwei bis drei Wochen entfernen. Wer einen Versionsstand fährt, der Events noch nicht nutzt, kann die Migration aufs nächste Release legen.
Der eigentliche Hebel liegt nicht in der Migration, sondern in der neuen Granularität. Wer added, updated und removed sauber auswertet, kann Sync-Jobs deutlich schlanker bauen – inkrementelle Updates statt Full-Sync. Das ist der Punkt, an dem sich der Aufwand rechnet.