Migrering fra Shopify Global Catalog API: Nå det inden novemberfristen

Shopifys Global Catalog API-migrering har en fast tidsfrist: 2. november 2026. Hvis en app, som din forretning er afhængig af, stadig kalder Global Catalog REST API'en, skal den flyttes til Global Catalog MCP, før tjenesten stopper med at håndtere trafik. Det første spørgsmål er, om noget, du kører, er afhængigt af det udfasede endepunkt. Her er hvordan vi vil identificere disse afhængigheder, definere arbejdsomfanget og teste erstatningen uden at forvandle en specifik API-ændring til en unødvendig genopbygning.

Hvad Shopify Global Catalog API-migreringen påvirker

Shopifys udviklerannoncering fra 9. oktober siger, at Global Catalog REST API'en, som blev markeret som forældet i april 2026, stopper med at håndtere trafik den 2. november. Shopify peger på Global Catalog MCP, der implementerer Universal Commerce Protocol (UCP), som dens erstatning. Datoen for nedlukningen fremgår også af udvikler-changeloggen.

Annonceringen vedrører Global Catalog REST API'en. Det betyder ikke, at enhver Shopify-integration bygget på REST stopper med at virke den 2. november. Denne sondring er vigtig, når man briefer et bureau eller en app-udbyder. En bred anmodning om at "migrere vores Shopify API'er" kan skabe forvirring og spilde den begrænsede tid, der er til rådighed.

Ændringen påvirker udviklere og virksomheder, hvis apps kalder denne specifikke API. En købmand uden en sådan afhængighed har ingen migrering at fuldføre på grund af denne annoncering. En købmand, hvis kundevendte produktsøgning er afhængig af en påvirket app, har brug for svar fra appens ejer nu.

Vores synspunkt: Betragt dette som en afhængighedsgennemgang, der kan føre til en migrering. Start ikke med et udviklingstilbud. Start med bevis for, at du er påvirket.

Find ud af, om din butik har en afhængighed

Bed de personer, der er ansvarlige for dine tilpassede integrationer, om at gennemgå kode og faktisk trafik. En liste over installerede apps er et nyttigt udgangspunkt, men den afslører muligvis ikke en ekstern tjeneste eller en prototype, som nogen har sat i produktion.

Giv hver ejer et klart formuleret spørgsmål: "Er der nogen produktionstjeneste, planlagt job eller aktivt eksperiment, der kalder Shopifys Global Catalog REST API?" Bed dem om at skelne det fra andre Shopify API'er.

• Tilpassede applikationer: Søg i repositories, konfiguration og deployments-historik efter referencer til den udfasede tjeneste.
• Tredjepartsværktøjer: Bed udbyderen om skriftligt at bekræfte, om de er påvirket, og hvis det er tilfældet, oplyse deres tidsplan for migrering.
• Eksperimenter: Inkluder produktsøgnings-demoer og agent-integrationer, som kunder eller medarbejdere stadig bruger.
• Planlagte jobs: Gennemgå nok historik til at fange jobs, der kører sjældent. En rolig eftermiddag i logfilerne er ikke bevis for, at en afhængighed er ubrugt.

For hver bekræftet afhængighed skal du registrere ejeren, formålet og hvor den kører i produktion. Tilføj det senest observerede kald og hvad der sker, hvis det fejler. "Kunder mister et produktanbefalingspanel" og "et internt eksperiment stopper med at opdatere" bør ikke have samme prioritet.

Hold også en liste over "ikke-påvirkede" med understøttende beviser. Det forhindrer det samme spørgsmål i at cirkulere de næste to uger.

Definer migreringen omkring adfærd

Shopify identificerer Global Catalog MCP som erstatningen. Det betyder ikke, at arbejdet blot er en URL-udskiftning. Annonceringen alene specificerer ikke alt, hvad din implementering får brug for.

Din udvikler bør tjekke erstatningens aktuelle adgangskrav og understøttede operationer i forhold til applikationens behov. Gennemgå eksplicit, hvordan anmodninger konstrueres, hvordan svar håndteres, og hvordan fejl administreres. Gå ikke ud fra, at velkendte REST-mønstre vil fungere uændret.

Dokumenter den eksisterende kontrakt

Inden du ændrer kode, skal du beskrive, hvad integrationen gør i dag i vendinger, som en købmand kan tjekke. For eksempel: en kunde søger efter et produkt, appen henter matchende produkter, og interfacet viser et tilbud med link til den korrekte destination.

Dette er et illustrativt flow, ikke en beskrivelse af enhver Catalog-integration. Din kontrakt kan i stedet vedrøre en baggrundsproces. Pointen er at dokumentere observerbar adfærd, ikke at bevare implementeringsdetaljer, som ingen har brug for.

Indsaml repræsentative input og forventede resultater. Inkluder en søgning, der ikke returnerer nogen resultater, samt produkter med flere varianter. Beslut hvilke felter appen har brug for for at fungere, og hvilke den kan undvære uden at vildlede nogen.

Adskil nødvendigt arbejde fra fristende tilføjelser

En migrering under tidspres er det forkerte tidspunkt at introducere en ny anbefalingsstrategi. Bevar den påkrævede adfærd først. Læg valgfrie forbedringer i en separat udgivelse, medmindre erstatningen gør dem nødvendige.

Hvor det er praktisk, vil vi også placere udbyderspecifikke kald bag en lille adapter. Det lader resten af appen bruge et stabilt internt format. Det kræver lidt mere arbejde nu, så spring avanceret abstraktion over for et eksperiment, der alligevel bliver kasseret. For en vedligeholdt produktionstjeneste er adskillelsen normalt værd at overveje.

Brug prisopdateringen som en regressionstest

En separat ændring fra 9. oktober gør prishåndtering særligt relevant. Shopifys Catalog API-opdatering siger, at en købmands sammenligningspris (compare-at price) kan optræde i det valgfrie variantfelt list_price. Det eksisterende price-felt ændres ikke.

Ifølge Shopify bruger list_price det samme Price-objekt som price, med et beløb i valutaens mindste enheder og en valuta. Produkter returnerer også list_price_range, der indeholder den laveste og højeste list_price på tværs af produktets varianter. Feltet er en del af UCP-katalogspecifikationen, version 2026-08-25.

Shopifys udviklerdokumentation siger, at list_price kun returneres, når købmanden deler sammenligningspriser gennem Catalog Mapping, sammenligningsprisen er højere end prisen i køberens kontekst, og købmanden viser sammenligningspriser i køberens region. For EØS-købere returneres feltet ikke, hvis butikken skjuler sammenligningspriser dér.

For købmænd er dette en grund til at gennemgå de referencepriser, du offentliggør. For udviklere er det en nyttig regressionstest under migreringen. Det er en separat opdatering, og Shopify siger, at selve det nye felt ikke kræver nogen handling. Forveksl det ikke med den obligatoriske udfasning.

• Manglende list_price: Shopify siger, at et manglende felt betyder, at der ikke returneres nogen sammenligningspris for den pågældende køber og konfiguration. Udled ikke mere uden at tjekke konteksten.
• Beløbsformatering: Tolk valutaens mindste enheder korrekt. Anvend ikke en universel decimalomregning uden at tjekke valutaens regler.
• Variantmatching: Beregn en vist besparelse ud fra den aktuelle pris og list_price for den samme variant, i den samme valuta.
• Produktprisintervaller: Kombiner ikke endepunkter fra forskellige intervaller for at skabe en rabatpåstand, som ingen individuel variant understøtter.

Som en illustrativ test: en variant prissat til 800 SEK med en sammenligningspris på 1.000 SEK er sat ned med 20 %. En anden variants referencepris kan ikke bruges som nævner i den beregning. En offentliggjort sammenligningspris etablerer heller ikke i sig selv, at en markedsføringspåstand overholder lokale prisregler.

Lav en overgangsplan, der virker efter 2. november

Pr. 12. oktober er der cirka tre uger tilbage før tidsfristen. Det er nok til en kontrolleret migrering, hvis du hurtigt identificerer ejeren. Det giver kun lidt plads til en afhængighed uden en ansvarlig, der opdages i slutningen af måneden.

Datoerne nedenfor er vores anbefalede tidsplan for arbejdet, ikke yderligere Shopify-tidsfrister.

Inden 14. oktober: fuldfør afhængighedsgennemgangen

Bekræft hvilke tjenester der er påvirket, og tildel en ejer til hver. Hvis en udbyder endnu ikke kan bekræfte, om de bruger den udfasede API, så hold den afhængighed markeret som uløst. Tavshed er ikke bevis for, at den er sikker.

Inden 21. oktober: demonstrer, at erstatningen virker

Kør erstatningen gennem repræsentative flows i et ikke-produktionsmiljø. Sammenlign forretningsresultater i stedet for at kræve identiske svarstrukturer. Registrer manglende funktioner tidligt nok til at kunne vælge en reserveplan.

Inden 28. oktober: flyt produktionstrafikken

Efterlad en buffer før nedlukningen. Overvåg succesrater for anmodninger og svartider, og tjek derefter det kundevendte resultat. Et succesfuldt netværkskald er ikke nok, hvis interfacet viser den forkerte variant eller ikke kan åbne det rigtige produkt.

Inden 2. november: fjern den gamle afhængighed

Tjek trafik og planlagte jobs igen. Deaktiver forældede stier og opdater driftsdokumentationen. Sørg for, at nogen har ansvaret for at tjekke den første normale kørsel efter nedlukningen.

Efter udfasningen er det ikke en mulighed at rulle tilbage til den udfasede API. Definer en reserveplan, der ikke har brug for den. Afhængigt af applikationen kan det betyde midlertidigt at fjerne et valgfrit produktsøgningsmodul eller dirigere kunder til butikkens eksisterende søgning. Undgå forældede prisvisninger som standard-reserveplan.

Hvad man skal spørge en app-udbyder om før godkendelse

En udbyders "vi understøtter Shopify" er for bredt. Spørg om deres produktionstjeneste bruger den påvirkede API, om erstatningen allerede er i drift, og hvilket bevis der demonstrerer parathed. Bed om en planlagt overgangsdato, hvis der stadig er arbejde tilbage.

For et betalt værktøj ville vi også spørge, hvad kunderne oplever, når erstatningen ikke er tilgængelig. Det er et rimeligt købskriterium: en nyttig app bør have forståelig fejl-adfærd. Små købmænd bør ikke behøve at kortlægge en udbyders infrastruktur for at finde ud af, om et produktpanel vil forsvinde.

Luk kun sagen, når der er beviser: enten kalder tjenesten ikke den udfasede API, eller også virker erstatningen i produktion, og de gamle kald er stoppet. En gennemført kodeændring, der ikke er blevet deployeret, efterlader risikoen præcis, hvor den var.

Opsummering

• Global Catalog REST API'en stopper med at håndtere trafik den 2. november 2026. Bekræft om du er afhængig af den, før du bestiller arbejde.
• Migrer påvirkede integrationer til Global Catalog MCP og test den adfærd, som kunder eller medarbejdere er afhængige af.
• Inkluder valgfrie sammenligningspriser og beløbshåndtering på variantniveau i regressionstests.
• Fuldfør overgangen før tidsfristen og vælg en reserveplan, der ikke afhænger af den udfasede API.

Kilder

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

Vil du have os til at håndtere det?

Vi er et Shopify Premier-bureau, og dette er vores daglige arbejde: performance, konverteringsoptimering (CRO) og butiksopbygning fokuseret på resultater. Book en gratis butiksvurdering, så viser vi dig de tre ændringer, vi ville lave først.

Ofte stillede spørgsmål

Hvornår stopper Shopifys Global Catalog REST API med at virke?

Ifølge Shopify stopper Global Catalog REST API'en med at håndtere trafik den 2. november 2026. Den blev markeret som forældet i april 2026. Påvirkede apps skal migreres før nedlukningen.

Skal enhver Shopify-butik migrere fra Global Catalog API'en?

Nej. Annonceringen vedrører apps, der kalder Global Catalog REST API'en. Bed dine udviklere og app-udbydere om at tjekke, om nogen produktionstjeneste eller planlagte jobs bruger den.

Hvad erstatter Shopifys Global Catalog REST API?

Shopify peger på Global Catalog MCP, som implementerer Universal Commerce Protocol, som erstatningen. Udviklere bør tjekke dens aktuelle krav og understøttede operationer i stedet for at gå ud fra, at migreringen blot er en URL-ændring.

Hvad betyder list_price i Shopify Catalog?

list_price er et valgfrit variantfelt til købmandens sammenligningspris. Det bruger et Price-objekt med et beløb i valutaens mindste enheder og en valuta. Det eksisterende price-felt er uændret. Shopify returnerer kun feltet, når betingelserne for køberens kontekst og købmandens indstillinger er opfyldt.

Kan en app vende tilbage til den gamle Global Catalog REST API efter 2. november?

Nej. Det er ikke en brugbar reserveplan, når API'en er holdt op med at håndtere trafik. Planlæg for en reduceret oplevelse eller en anden understøttet vej, der ikke afhænger af den udfasede tjeneste.