2 Minuten Lesezeit. Das Update betrifft jeden, der Draft Orders über die Shopify Admin API erstellt oder bearbeitet — also praktisch jede mittlere und größere Integration im DACH-Raum.
Mit Version 2026-10 der GraphQL Admin API entfernt Shopify das Feld priceRule vom Objekt DraftOrderDiscountNotAppliedWarning. Wer es noch in Queries oder Mutationen wie draftOrderCalculate, draftOrderCreate oder draftOrderUpdate abfragt, bekommt keine Warnung mehr, sondern einen harten Schema-Fehler. Für Händler und Agenturen, die ihre Preisregeln, Gutscheine oder B2B-Konditionen über kundenspezifische Draft Orders abbilden, ist das kein kosmetisches Detail. Es ist ein weiterer Schritt in Shopifys längerem Prozess, die Discount-Architektur vom historischen PriceRule-Modell in Richtung spezifischerer Discount-Typen zu verschieben.
Warum entfernt Shopify gerade dieses Feld?
Die Antwort liegt in der Geschichte der Shopify-Discounts. Jahre lang waren Preisregeln und Rabattcodes über das PriceRule-Objekt miteinander verwoben. Ein PriceRule definierte die Bedingungen, ein DiscountCode war der auslösende Mechanismus. Das war technisch elegant, aber für Draft Orders unpraktisch: Wenn ein Rabatt nicht angewendet werden konnte, musste die API dem Aufrufer mitteilen, welche Regel blockiert war — ohne klar zu sagen, ob es sich um einen automatischen Rabatt, einen Gutscheincode oder eine andere Discount-Anwendung handelte.
Mit der Einführung differenzierterer Typen wie DiscountCodeApplication, AutomaticDiscount und ManualDiscount machte Shopify das expliziter. Das Feld priceRule auf DraftOrderDiscountNotAppliedWarning wurde deshalb als deprecated markiert. In 2026-10 fällt es nun endgültig weg. Statt einer generischen Regel-ID liefert die API künftig gezieltere Felder, die direkt auf den konkreten Discount-Typ verweisen. Das reduziert Mehrdeutigkeit — und zwingt Entwickler dazu, ihre Logik an die aktuelle Architektur anzupassen.
Wer im DACH-Markt ist konkret betroffen?
Jede Integration, die Draft Orders mit Rabattlogik anreichert. Das sind in Deutschland, Österreich und der Schweiz erstaunlich viele Systeme: ERP-Anbindungen, die Händleraufträge als Draft Orders vorbereiten; Telefonvertriebs-Tools, bei denen Kundenberater manuelle Nachlässe erfassen; B2B-Portale, die kundenspezifische Preise über Draft Orders abbilden; und natürlich Gutschein-Apps, die prüfen, warum ein Code an einer Bestellung scheitert.
Ein typisches Szenario: Ein Shopify Plus-Händler aus München importiert täglich Aufträge aus seinem WaWi-System. Wenn ein Rabatt nicht greift, wird die Warnung ausgelesen und ins interne Logistik-System zurückgespielt. Bisher lieferte priceRule die ID der Preisregel, über die das Tool den Fehler zuordnen konnte. Ab 2026-10 bricht diese Zuordnung weg, wenn das Feld weiterhin abgefragt wird. Konkret bedeutet das: Die Integration liefert keine Aufträge mehr, bis der Entwickler den Query anpasst.
Besonders brisant ist die Stille vor dem Sturm. Anders als bei vielen anderen Breaking Changes meldet Shopify das Problem nicht proaktiv im Admin-Backend. Es fällt erst auf, wenn die API-Version umgestellt wird — oder wenn die App plötzlich Fehler wirft, weil der Header X-Shopify-API-Version auf 2026-10 oder höher zeigt.
Wie sieht die Migration in der Praxis aus?
Der erste Schritt ist eine Abfrage-Audit. Entwickler müssen alle Stellen finden, an denen DraftOrderDiscountNotAppliedWarning verwendet wird und das Feld priceRule enthalten ist. In den meisten Codebases dürfte das nur wenige Queries betreffen, aber gerade bei älteren Apps oder monolithischen ERP-Integrationen kann sich das Feld versteckt haben.
Der zweite Schritt ist die Ersetzung. Shopify empfiehlt, statt priceRule auf die spezifischen Discount-Felder auszuweichen. Je nach App-Logik kommt dafür automaticDiscount, discountCode oder discountCodeApplication infrage. Die korrekte Wahl hängt davon ab, ob die App automatische Rabatte, klassische Gutscheincodes oder beides verarbeitet. Hier lohnt sich ein Blick in die aktuelle Schema-Dokumentation der jeweiligen API-Version, denn die verfügbaren Felder können sich zwischen Releases leicht unterscheiden.
Der dritte Schritt ist das Testen gegen reale Draft-Order-Szenarien. Nicht jeder Rabattfehler lässt sich in einer sauberen Entwicklungsumgebung reproduzieren. Händler sollten mit ihren Agenturen gezielt Testfälle bauen: Ein ungültiger Gutscheincode, ein automatischer Rabatt, der durch die Artikelauswahl nicht greift, und ein manueller Rabatt, der die Mindestbestellmenge verfehlt. Nur so lässt sich sicherstellen, dass die neue Feldstruktur alle Fehlerarten korrekt abbildet.
Welche strategische Bedeutung hat diese Änderung?
Das Entfernen eines einzelnen Feldes mag klein wirken. Im Kontext von Shopifys API-Strategie ist es aber symptomatisch. Der Plattformanbieter räumt Altlasten aus, die aus der Zeit stammen, als Discounts noch primär über PriceRules modelliert wurden. Das Ziel ist klar: eine konsistentere, typensichere API, die den Unterschied zwischen automatischen Rabatten, Gutscheinen und manuellen Nachlässen nicht mehr dem Entwickler überlässt.
Für DACH-Händler hat das zwei Konsequenzen. Zum einen steigt der Pflegeaufwand für eigene Integrationen. Shopify veröffentlicht alle drei Monate eine neue API-Version, die jeweils zwölf Monate lang unterstützt wird. Wer heute noch auf 2025-07 oder älter sitzt, muss nicht nur dieses Feld ersetzen, sondern meist mehrere Breaking Changes auf einmal nachholen. Zum anderen profitieren sauber migrierte Systeme von einer stabilen Fehlerbehandlung. Wenn Rabatte nicht greifen, weiß das Backend künftig früher und präziser, woran es liegt — und kann dem Kunden eine aussagekräftigere Rückmeldung geben.
„Die Migration ist nicht optional. Wer die API-Version nicht anhebt, bleibt irgendwann ohne Support. Wer sie anhebt, ohne die Deprecations zu prüfen, bekommt Produktionsausfälle.“
Was Händler jetzt tun sollten
Der beste Zeitpunkt für die Umstellung ist jetzt, nicht im Herbst 2026. Händler mit eigenen Apps oder maßgeschneiderten Integrationen sollten ihren Entwicklern drei Aufgaben geben: Erstens, alle Queries auf DraftOrderDiscountNotAppliedWarning identifizieren. Zweitens, priceRule durch die passenden Ersatzfelder ersetzen. Drittens, die API-Version schrittweise in einer Staging-Umgebung auf 2026-10 anheben, bevor der Produktivbetrieb umgestellt wird.
Shopify Plus-Händler mit komplexem Gutschein- und Rabattsetup sollten zusätzlich prüfen, ob ihre Discount-Strategie überhaupt noch mit der aktuellen Architektur harmoniert. Viele ältere Workflows basieren noch auf manuellen Preisregeln, die inzwischen besser über automatische Rabatte oder B2B-Katalogpreise abgebildet werden. Die API-Änderung ist damit auch ein Anlass, das eigene Discount-Design zu hinterfragen — nicht nur den Code.
Die Botschaft ist einfach: Shopify räumt auf. Wer mitzieht, gewinnt Stabilität. Wer zögert, riskiert, dass seine Draft-Order-Integrationen im Herbst 2026 stillschweigend aussteigen.