Migration der Shopify Global Catalog API: Rechtzeitig vor der November-Frist handeln

Die Migration der Global Catalog API von Shopify hat eine feste Deadline: den 2. November 2026. Wenn eine App, von der Ihr Unternehmen abhängt, weiterhin die Global Catalog REST API aufruft, muss sie auf das Global Catalog MCP umgestellt werden, bevor der Dienst den Betrieb einstellt. Die erste Frage ist, ob irgendetwas, das Sie betreiben, von dem auslaufenden Endpunkt abhängt. Hier erfahren Sie, wie wir diese Abhängigkeiten identifizieren, den Arbeitsaufwand einschätzen und den Ersatz testen, ohne eine spezifische API-Änderung in einen unnötigen kompletten Umbau zu verwandeln.

Was die Migration der Shopify Global Catalog API betrifft

In der Ankündigung für Entwickler vom 9. Oktober gibt Shopify bekannt, dass die im April 2026 als veraltet markierte Global Catalog REST API am 2. November den Betrieb einstellt. Shopify bezeichnet das Global Catalog MCP, das das Universal Commerce Protocol (UCP) implementiert, als Ersatz. Das Abschaltdatum findet sich auch im Entwickler-Changelog.

Die Ankündigung betrifft die Global Catalog REST API. Das bedeutet nicht, dass jede Shopify-Integration, die auf REST basiert, am 2. November nicht mehr funktioniert. Diese Unterscheidung ist wichtig, wenn Sie eine Agentur oder einen App-Anbieter briefen. Eine pauschale Aufforderung, „unsere Shopify-APIs zu migrieren“, kann zu Verwirrung führen und die begrenzte Zeit verschwenden.

Die Änderung betrifft Entwickler und Unternehmen, deren Apps diese spezifische API aufrufen. Ein Händler ohne eine solche Abhängigkeit muss aufgrund dieser Ankündigung keine Migration durchführen. Ein Händler, dessen kundenorientierte Produktsuche auf einer betroffenen App basiert, benötigt jetzt Antworten vom App-Anbieter.

Unsere Sichtweise: Betrachten Sie dies als Überprüfung von Abhängigkeiten, die zu einer Migration führen kann. Beginnen Sie nicht mit einem Entwicklungsangebot. Beginnen Sie mit dem Nachweis, dass Sie betroffen sind.

Finden Sie heraus, ob Ihr Shop eine Abhängigkeit hat

Bitten Sie die für Ihre individuellen Integrationen Verantwortlichen, den Code und den tatsächlichen Datenverkehr zu überprüfen. Eine Liste installierter Apps ist ein nützlicher Ausgangspunkt, zeigt aber möglicherweise keinen externen Dienst oder Prototyp, den jemand in die Produktion übernommen hat.

Geben Sie jedem Verantwortlichen eine klar formulierte Frage: „Ruft irgendein Produktionsdienst, ein geplanter Job oder ein aktives Experiment die Global Catalog REST API von Shopify auf?“ Bitten Sie sie, diese von anderen Shopify-APIs zu unterscheiden.

• Benutzerdefinierte Anwendungen: Durchsuchen Sie Repositories, Konfiguration und Bereitstellungshistorie nach Referenzen auf den auslaufenden Dienst.
• Drittanbieter-Tools: Bitten Sie den Anbieter, schriftlich zu bestätigen, ob er betroffen ist, und falls ja, seine Migrations-Timeline mitzuteilen.
• Experimente: Schließen Sie Demos zur Produktsuche und Agenten-Integrationen ein, die Kunden oder Mitarbeiter noch nutzen.
• Geplante Jobs: Überprüfen Sie genügend Historie, um Jobs zu erfassen, die selten ausgeführt werden. Ein ruhiger Nachmittag in den Protokollen beweist nicht, dass eine Abhängigkeit ungenutzt ist.

Notieren Sie für jede bestätigte Abhängigkeit den Verantwortlichen, den Zweck und den Ort des Produktionseinsatzes. Fügen Sie den zuletzt beobachteten Aufruf hinzu und was passiert, wenn er fehlschlägt. „Kunden verlieren ein Produktempfehlungs-Panel“ und „ein internes Experiment hört auf sich zu aktualisieren“ sollten nicht die gleiche Priorität haben.

Führen Sie auch eine Liste „nicht betroffen“ mit unterstützenden Belegen. Das verhindert, dass dieselbe Frage in den nächsten zwei Wochen immer wieder zirkuliert.

Den Umfang der Migration auf das Verhalten ausrichten

Shopify identifiziert Global Catalog MCP als Ersatz. Das bedeutet nicht, dass die Arbeit einfach ein URL-Tausch ist. Die Ankündigung allein spezifiziert nicht alles, was Ihre Implementierung benötigen wird.

Ihr Entwickler sollte die aktuellen Zugangsvoraussetzungen und unterstützten Operationen des Ersatzes mit den Anforderungen der Anwendung abgleichen. Überprüfen Sie explizit, wie Anfragen konstruiert, wie Antworten behandelt und wie Fehler verwaltet werden. Gehen Sie nicht davon aus, dass vertraute REST-Muster unverändert funktionieren.

Das bestehende Verhalten dokumentieren

Bevor Sie den Code ändern, beschreiben Sie, was die Integration heute tut, in einer Weise, die ein Händler überprüfen kann. Zum Beispiel: Ein Kunde sucht nach einem Produkt, die App ruft passende Produkte ab und das Interface zeigt ein Angebot mit Link zum richtigen Ziel an.

Dies ist ein illustrativer Ablauf, keine Beschreibung jeder Catalog-Integration. Diese Beschreibung könnte sich stattdessen auf einen Hintergrundprozess beziehen. Der Punkt ist, beobachtbares Verhalten zu dokumentieren, nicht Implementierungsdetails zu bewahren, die niemand braucht.

Sammeln Sie repräsentative Eingaben und erwartete Ergebnisse. Fügen Sie eine Suche ein, die keine Ergebnisse liefert, sowie Produkte mit mehreren Varianten. Entscheiden Sie, welche Felder die App zum Funktionieren benötigt und auf welche sie verzichten kann, ohne jemanden irrezuführen.

Notwendige Arbeit von reizvollen Ergänzungen trennen

Eine Migration unter Zeitdruck ist der falsche Moment, um eine neue Empfehlungsstrategie einzuführen. Bewahren Sie zuerst das erforderliche Verhalten. Verschieben Sie optionale Verbesserungen in ein separates Release, es sei denn, der Ersatz macht sie notwendig.

Wo praktikabel, würden wir anbieterspezifische Aufrufe hinter einen kleinen Adapter legen. Das lässt den Rest der App ein stabiles internes Format nutzen. Es bedeutet jetzt etwas mehr Arbeit, also überspringen Sie aufwendige Abstraktionen für ein Experiment, das ohnehin verworfen wird. Für einen gewarteten Produktionsdienst ist die Trennung meist eine Überlegung wert.

Nutzen Sie das Preis-Update als Regressionstest

Eine separate Änderung vom 9. Oktober macht die Preisbehandlung besonders relevant. Das Update der Shopify Catalog API besagt, dass der Vergleichspreis eines Händlers im optionalen Variantenfeld list_price erscheinen kann. Das bestehende price-Feld ändert sich nicht.

Laut Shopify verwendet list_price dasselbe Price-Objekt wie price, mit einem Betrag in den kleinsten Einheiten der jeweiligen Währung und einer Währung. Produkte geben auch list_price_range zurück, das den niedrigsten und höchsten list_price über die Varianten des Produkts hinweg enthält. Das Feld ist Teil der UCP Catalog-Spezifikation, Version 2026-08-25.

Die Entwicklerdokumentation von Shopify besagt, dass list_price nur zurückgegeben wird, wenn der Händler Vergleichspreise über Catalog Mapping teilt, der Vergleichspreis höher ist als der Preis im Kontext des Käufers und der Händler Vergleichspreise in der Region des Käufers anzeigt. Für Käufer im EWR wird das Feld nicht zurückgegeben, wenn der Shop Vergleichspreise dort ausblendet.

Für Händler ist dies ein Grund, die veröffentlichten Referenzpreise zu überprüfen. Für Entwickler ist es ein nützlicher Regressionstest während der Migration. Es ist ein separates Update, und Shopify sagt, dass das neue Feld selbst keine Maßnahmen erfordert. Verwechseln Sie es nicht mit der obligatorischen Stilllegung.

• Fehlender list_price: Shopify sagt, dass ein fehlendes Feld bedeutet, dass kein Vergleichspreis für diesen Käufer und diese Konfiguration zurückgegeben wird. Schließen Sie nicht mehr daraus, ohne den Kontext zu prüfen.
• Betragsformatierung: Interpretieren Sie die kleinsten Einheiten der jeweiligen Währung korrekt. Wenden Sie keine universelle Dezimalumrechnung an, ohne die Regeln der Währung zu prüfen.
• Variantenabgleich: Berechnen Sie eine angezeigte Ersparnis aus dem aktuellen Preis und list_price für dieselbe Variante in derselben Währung.
• Produktpreisspannen: Kombinieren Sie keine Endpunkte aus verschiedenen Bereichen, um eine Rabattaussage zu machen, den keine einzelne Variante unterstützt.

Als illustrativer Test: Eine Variante, die mit 800 SEK bepreist ist und einen Vergleichspreis von 1.000 SEK hat, ist um 20 % reduziert. Der Referenzpreis einer anderen Variante kann nicht als Nenner in dieser Berechnung verwendet werden. Ein veröffentlichter Vergleichspreis stellt auch für sich genommen nicht fest, dass ein Werbeversprechen den lokalen Preisvorschriften entspricht.

Einen Cutover-Plan erstellen, der nach dem 2. November funktioniert

Stand 12. Oktober verbleiben etwa drei Wochen bis zur Deadline. Das reicht für eine kontrollierte Migration, wenn Sie den Verantwortlichen schnell identifizieren. Es lässt wenig Raum für eine Abhängigkeit ohne Verantwortlichen, die erst Ende des Monats entdeckt wird.

Die unten genannten Daten sind unser empfohlener Arbeitsplan, keine zusätzlichen Shopify-Deadlines.

Bis 14. Oktober: Abschluss der Abhängigkeitsprüfung

Bestätigen Sie, welche Dienste betroffen sind, und weisen Sie jedem einen Verantwortlichen zu. Wenn ein Anbieter noch nicht bestätigen kann, ob er die auslaufende API nutzt, markieren Sie diese Abhängigkeit als ungelöst. Schweigen ist kein Beweis dafür, dass es sicher ist.

Bis 21. Oktober: Demonstrieren, dass der Ersatz funktioniert

Lassen Sie den Ersatz durch repräsentative Abläufe in einer Nicht-Produktionsumgebung laufen. Vergleichen Sie Geschäftsergebnisse, anstatt identische Antwortstrukturen zu fordern. Erfassen Sie fehlende Fähigkeiten früh genug, um ein Fallback zu wählen.

Bis 28. Oktober: Produktionsverkehr verschieben

Lassen Sie einen Puffer vor der Abschaltung. Überwachen Sie Erfolgsraten und Antwortzeiten der Anfragen und überprüfen Sie dann das kundenorientierte Ergebnis. Ein erfolgreicher Netzwerkaufruf reicht nicht aus, wenn das Interface die falsche Variante anzeigt oder das richtige Produkt nicht öffnen kann.

Vor dem 2. November: Alte Abhängigkeit entfernen

Überprüfen Sie den Datenverkehr und geplante Jobs erneut. Deaktivieren Sie veraltete Pfade und aktualisieren Sie die Betriebsdokumentation. Stellen Sie sicher, dass jemand den ersten normalen Lauf nach der Abschaltung überprüft.

Nach der Außerbetriebnahme ist ein Rollback auf die alte API keine Option. Definieren Sie ein Fallback, das diese nicht benötigt. Je nach Anwendung könnte das bedeuten, ein optionales Produktsuchmodul vorübergehend zu entfernen oder Kunden auf die bestehende Suche des Shops zu leiten. Vermeiden Sie veraltete Preisanzeigen als Standard-Fallback.

Was Sie einen App-Anbieter vor der Abnahme fragen sollten

Ein „Wir unterstützen Shopify“ eines Anbieters ist zu vage. Fragen Sie, ob sein Produktionsdienst die betroffene API nutzt, ob der Ersatz bereits live ist und welche Belege die Bereitschaft demonstrieren. Fragen Sie nach einem geplanten Cutover-Datum, falls noch Arbeit aussteht.

Bei einem kostenpflichtigen Tool würden wir auch fragen, was Kunden erleben, wenn der Ersatz nicht verfügbar ist. Das ist ein vernünftiges Kaufkriterium: Eine nützliche App sollte ein verständliches Fehlerverhalten haben. Kleine Händler sollten nicht die Infrastruktur eines Anbieters abbilden müssen, um herauszufinden, ob ein Produkt-Panel verschwindet.

Schließen Sie das Thema erst ab, wenn Belege vorliegen: Entweder ruft der Dienst die auslaufende API nicht auf, oder der Ersatz funktioniert in der Produktion und die alten Aufrufe sind gestoppt. Eine abgeschlossene Code-Änderung, die nicht bereitgestellt wurde, belässt das Risiko genau dort, wo es war.

Zusammenfassung

• Die Global Catalog REST API stellt am 2. November 2026 den Betrieb ein. Bestätigen Sie, ob Sie davon abhängen, bevor Sie Arbeiten in Auftrag geben.
• Migrieren Sie betroffene Integrationen auf das Global Catalog MCP und testen Sie das Verhalten, auf das sich Kunden oder Mitarbeiter verlassen.
• Beziehen Sie optionale Vergleichspreise und die Handhabung von Beträgen auf Varianten-Ebene in Regressionstests ein.
• Schließen Sie den Umstieg vor der Deadline ab und wählen Sie ein Fallback, das nicht von der eingestellten API abhängt.

Quellen

• Global Catalog REST API stops serving traffic on November 2, 2026
• Catalog API now returns compare-at prices as list_price

Sollen wir das für Sie erledigen?

Wir sind eine Shopify Premier Agentur und das ist unser Tagesgeschäft: Performance, Conversion-Rate-Optimierung (CRO) und auf Ergebnisse fokussierte Shop-Entwicklung. Buchen Sie einen kostenlosen Shop-Check und wir zeigen Ihnen die drei Änderungen, die wir zuerst vornehmen würden.

Häufig gestellte Fragen

Wann hört die Shopify Global Catalog REST API auf zu funktionieren?

Laut Shopify stellt die Global Catalog REST API am 2. November 2026 den Betrieb ein. Sie wurde im April 2026 als veraltet markiert. Betroffene Apps müssen vor der Abschaltung migrieren.

Muss jeder Shopify-Shop von der Global Catalog API migrieren?

Nein. Die Ankündigung betrifft Apps, die die Global Catalog REST API aufrufen. Bitten Sie Ihre Entwickler und App-Anbieter zu prüfen, ob irgendein Produktionsdienst oder geplanter Job sie nutzt.

Was ersetzt die Shopify Global Catalog REST API?

Shopify identifiziert das Global Catalog MCP, das das Universal Commerce Protocol implementiert, als Ersatz. Entwickler sollten dessen aktuelle Anforderungen und unterstützte Operationen prüfen, anstatt anzunehmen, die Migration sei nur eine URL-Änderung.

Was bedeutet list_price im Shopify Katalog?

list_price ist ein optionales Variantenfeld für den Vergleichspreis des Händlers. Es verwendet ein Price-Objekt mit einem Betrag in den kleinsten Einheiten der jeweiligen Währung und einer Währung. Das bestehende price-Feld bleibt unverändert. Shopify gibt das Feld nur zurück, wenn die Bedingungen für den Kontext des Käufers und die Einstellungen des Händlers erfüllt sind.

Kann eine App nach dem 2. November zur alten Global Catalog REST API zurückkehren?

Nein. Das ist kein gangbares Fallback, sobald die API den Betrieb eingestellt hat. Planen Sie für ein eingeschränktes Erlebnis oder einen anderen unterstützten Pfad, der nicht von dem eingestellten Dienst abhängt.