Ein einzelnes Boolean-Feld bringt Shopify-Apps zum Absturz. Wer in der GraphQL Admin API ab Version 2027-01 den Wert includeRestOfWorld: true im Input DiscountCountriesInput setzt, bekommt keine stille Deprecation-Warnung mehr, sondern einen harten BAD_REQUEST. Die Rabattlogik für internationale Märkte verliert damit ihren bequemen Fallback — und zahlreiche Discount-Apps müssen vor dem Versionssprung ihre Länderlisten neu bauen.
Wer heute auf 2026-10 oder älter läuft, merkt nichts. Diese Versionen behalten das alte Verhalten, solange Shopify sie unterstützt. Der Bruch kommt erst mit dem API-Upgrade — dann aber ohne Übergangsfrist auf Feldebene.
Was ändert sich konkret in API-Version 2027-01?
Das Feld includeRestOfWorld gehörte zur Eingabestruktur, mit der ein Discount auf bestimmte Zielmärkte begrenzt wird. Der Wert true bedeutete: Der Rabatt gilt in allen Ländern, die nicht explizit in der Liste stehen — die sogenannte Rest-of-World-Menge. Genau diese Sammelmenge ist in 2027-01 nicht mehr zulässig.
Ab der neuen Version musst du jedes anwendbare Land einzeln über die Feldliste add übergeben. Der Server akzeptiert kein implizites „und der Rest der Welt“. Ein Aufruf, der vorher durchging, gibt jetzt einen BAD_REQUEST zurück — in der Regel begleitet von einer Fehlermeldung, die auf das deprecated Feld verweist.
Für Entwickler ist das kein kosmetischer Fehler. Ein BAD_REQUEST bricht in der Regel die gesamte Mutation ab. Wer Rabatte programmatisch anlegt — etwa im Rahmen eines Preisimports oder einer Kampagnen-Automatisierung — muss damit rechnen, dass die komplette Discount-Erstellung fehlschlägt, nicht nur das eine Feld.
Warum entfernt Shopify die Rest-of-World-Abkürzung?
Die wahrscheinlichste Erklärung liegt in der Konsistenz der Länderlogik über die gesamte Admin API hinweg. Ein Rabatt, der „überall außer X“ gilt, ist schwer zu prüfen: Welche Länder gehören zur Restmenge, wenn Shopify neue Märkte erschließt? Ändert sich die Menge automatisch mit dem Markt-Rollout? Genau diese Unschärfe verschwindet, wenn nur noch explizite Länderlisten akzeptiert werden.
Shopify zieht damit eine Grenze zwischen Marktabdeckung und Rabattdefinition. Marktabdeckung wird über Markets gesteuert — also über die Strukturen, mit denen Händler Regionen, Währungen und Domains bündeln. Rabatte dagegen adressieren künftig eine feste, benannte Ländermenge. Das ist mehr Arbeit im Setup, aber es macht Discounts reproduzierbar.
Ein Rabatt ist ein Vertrag mit dem Kunden. Verträge über eine dynamische Restmenge zu definieren, war immer ein Kompromiss.
Wie betroffen sind Discount-Apps im DACH-Markt?
Wer im deutschsprachigen Raum mit Shopify Plus arbeitet und Rabatte über eigene Apps, ERP-Anbindungen oder PIM-Systeme ausrollt, ist unmittelbar betroffen. Der typische Fehlerpfad: Ein Skript legt einen Rabatt für „alle Märkte außer AT und CH“ an — also DACH-weit mit Ausnahmen. Genau dieses Muster funktioniert in 2027-01 nicht mehr.
Betroffen sind vor allem:
- Eigenentwicklungen, die Discounts per GraphQL-Mutation erzeugen und auf includeRestOfWorld als Default setzen.
- Drittanbieter-Apps für Rabatt- und Promotion-Management, die ihre Länderlisten noch nicht migriert haben.
- Middleware- und Integrationsschichten (z.B. zwischen Shop und ERP), die Rabattregeln aus Fremdsystemen übersetzen.
Reine Standard-Shops, die Rabatte im Admin-UI per Maus anlegen, sind weniger betroffen — dort erzeugt die Oberfläche die Länderliste ohnehin explizit. Das Risiko liegt in der Automatisierung.
Welche Länderliste brauchst du statt includeRestOfWorld?
Die Antwort ist unspektakulär, aber vollständig: Die vollständige Liste der Zielländer. Statt einer Abkürzung hinterlegst du jedes Land, in dem der Rabatt gelten soll, als einzelnen Eintrag über add. Bei einem Shop, der in 40 Ländern verkauft, sind das 40 Einträge im Input.
Für die meisten Händler ist das kein Problem — es ist eine einmalige Migration pro Rabatt-Template. Kritischer wird es bei dynamischen Szenarien: Wenn sich die Zielländer je Kampagne ändern, muss die Liste jedes Mal neu aufgebaut werden. Wer hier bisher auf „Rest der Welt“ vertraut hat, braucht jetzt eine belastbare Quelle für die Länderliste — idealerweise aus den Shopify-Markets oder einem gepflegten Länderstamm im ERP.
Wie migrierst du ohne Ausfall?
Der entscheidende Punkt ist die Reihenfolge. Apps, die noch auf 2026-10 laufen, sollten nicht einfach die Version hochziehen und hoffen. Sinnvoll ist ein dreistufiger Ablauf:
Erstens — Bestandsaufnahme: Suche im Code nach jeder Verwendung von includeRestOfWorld. In GraphQL-Projekten reicht oft eine Textsuche über das Repository. Für Drittanbieter-Apps lohnt der Blick in die Release Notes des Anbieters; viele haben die Migration bereits umgesetzt oder planen sie zum Versionssprung.
Zweitens — Länderquelle festlegen: Bestimme, aus welcher Quelle die explizite Länderliste künftig kommt. Bei Shopify-nativen Setups sind es die Markets, bei integrierten Systemen das ERP oder eine zentrale Länder-Tabelle. Diese Quelle muss vollständig sein, sonst fehlen Rabatte in einzelnen Märkten.
Drittens — Parallel testen: Baue eine Testumgebung, die bereits auf 2027-01 läuft, und spiele die Discount-Erstellung durch. Prüfe nicht nur, ob der Call durchgeht, sondern ob der Rabatt in jedem Zielland tatsächlich greift — inklusive der Länder, die vorher über die Restmenge abgedeckt waren.
Wer bis kurz vor dem Versionsende wartet, riskiert, dass Rabattkampagnen mitten im Betrieb ausfallen. Der Fehler tritt erst bei der neuen Version auf — bis dahin bleibt das Problem unsichtbar.
Was heißt das für die Zukunft der Discount-Steuerung?
Die Änderung ist ein weiterer Beleg für eine Entwicklung, die sich über die gesamte Admin API zieht: implizite Mengen und Default-Verhalten verschwinden, explizite Definitionen bleiben. Für Händler bedeutet das mehr Pflegeaufwand, aber auch mehr Kontrolle. Ein Rabatt, der in einer Liste steht, lässt sich prüfen. Ein Rabatt, der „überall außer X“ gilt, lässt sich nur schwer nachvollziehen.
Praktisch heißt die Empfehlung: Wer Rabatte automatisiert, sollte die Länderliste so früh wie möglich auf explizite Einträge umstellen — auch in Versionen, in denen includeRestOfWorld noch funktioniert. Dann ist der Versionssprung keine Zäsur, sondern ein Nebeneffekt. Und wer eine Discount-App einsetzt, sollte den Anbieter jetzt konkret fragen, wann die 2027-01-Kompatibilität kommt — nicht ob.