Shopifyn Global Catalog API -migraatiolla on kiinteä takaraja: 2. marraskuuta 2026. Jos sovellus, josta yrityksesi toiminta riippuu, kutsuu yhä Global Catalog REST API -rajapintaa, sen on siirryttävä Global Catalog MCP -rajapintaan ennen kuin palvelu lakkaa toimimasta. Ensimmäinen kysymys on se, riippuuko mikään käyttämäsi järjestelmä tästä poistuvasta päätepisteestä. Tässä kerromme, miten tunnistamme kyseiset riippuvuudet, määrittelemme työn laajuuden ja testaamme korvaavan ratkaisun ilman, että API-muutoksesta tulee tarpeettoman laaja uudelleenrakennusprojekti.
Mitä Shopifyn Global Catalog API -migraatio koskee
Shopifyn 9. lokakuuta julkaiseman kehittäjätiedotteen mukaan Global Catalog REST API, joka merkittiin vanhentuneeksi huhtikuussa 2026, lakkaa palvelemasta liikennettä 2. marraskuuta. Shopify nimeää korvaajaksi Universal Commerce Protocol (UCP) -protokollaa toteuttavan Global Catalog MCP:n. Sammutuspäivämäärä näkyy myös kehittäjien muutoslokissa.
Tiedote koskee Global Catalog REST API -rajapintaa. Se ei tarkoita, että jokainen REST-pohjainen Shopify-integraatio lakkaisi toimimasta 2. marraskuuta. Tämä erottelu on tärkeää, kun ohjeistat toimistoa tai sovellustoimittajaa. Laaja pyyntö "migroida Shopify-rajapintamme" voi aiheuttaa sekaannusta ja hukata rajallista aikaa.
Muutos koskee kehittäjiä ja yrityksiä, joiden sovellukset kutsuvat tätä nimenomaista rajapintaa. Kauppiaalla, jolla ei ole tällaista riippuvuutta, ei ole tarvetta migraatiolle tämän tiedotteen vuoksi. Kauppiaan, jonka asiakasrajapinnan tuotehaku perustuu tällaiseen sovellukseen, on saatava vastaukset sovelluksen omistajalta nyt.
Näkemyksemme: käsittele tätä riippuvuuskatsauksena, joka voi johtaa migraatioon. Älä aloita kehitystyötarjouksen pyytämisellä, vaan näytöillä siitä, että olet muutoksen kohteena.
Selvitä, onko kaupallasi riippuvuutta
Pyydä mukautetuista integraatioista vastaavia henkilöitä tarkistamaan koodi ja todellinen verkkoliikenne. Lista asennetuista sovelluksista on hyödyllinen lähtökohta, mutta se ei välttämättä paljasta ulkoista palvelua tai prototyyppiä, jonka joku on vienyt tuotantoon.
Anna jokaiselle vastuuhenkilölle selkeä kysymys: "Kutsuuko mikään tuotantopalvelu, ajastettu tehtävä tai aktiivinen kokeilu Shopifyn Global Catalog REST API -rajapintaa?" Pyydä heitä erottamaan se muista Shopify-rajapinnoista.
- Mukautetut sovellukset: Etsi arkistoista, konfiguraatioista ja käyttöönottohistoriasta viittauksia poistuvaan palveluun.
- Kolmannen osapuolen työkalut: Pyydä toimittajaa vahvistamaan kirjallisesti, koskeeko muutos heitä, ja jos koskee, pyydä migraation aikataulu.
- Kokeilut: Sisällytä mukaan tuotehaun demot ja agentti-integraatiot, joita asiakkaat tai henkilökunta yhä käyttävät.
- Ajastetut tehtävät: Tarkista riittävän pitkä historia, jotta löydät harvoin suoritettavat tehtävät. Hiljainen iltapäivä lokeissa ei todista, ettei riippuvuutta käytetä.
Kirjaa jokaisesta vahvistetusta riippuvuudesta sen omistaja, tarkoitus ja sijainti tuotannossa. Lisää tieto viimeisimmästä havaitusta kutsusta ja siitä, mitä tapahtuu, jos kutsu epäonnistuu. "Asiakkaat menettävät tuotesuosituspaneelin" ja "sisäinen kokeilu lakkaa päivittymästä" eivät saisi olla samalla prioriteetilla.
Pidä myös perusteltua listaa järjestelmistä, joihin muutos ei vaikuta. Se estää samaa kysymystä kiertämästä seuraavien kahden viikon aikana.
Määrittele migraation laajuus toimintojen perusteella
Shopify nimeää Global Catalog MCP:n korvaajaksi. Se ei tarkoita, että kyseessä on pelkkä URL-osoitteen vaihto. Tiedote yksinään ei määritä kaikkea, mitä toteutuksesi tarvitsee.
Kehittäjäsi tulisi tarkistaa korvaavan ratkaisun nykyiset pääsyvaatimukset ja tuetut toiminnot suhteessa sovelluksen tarpeisiin. Tarkista eksplisiittisesti, miten pyynnöt muodostetaan, miten vastaukset käsitellään ja miten virheitä hallitaan. Älä oleta, että tutut REST-mallit toimivat sellaisenaan.
Dokumentoi nykyinen toimintamalli
Ennen koodin muuttamista kuvaile, mitä integraatio tekee nykyään kauppiaan ymmärtämällä tavalla. Esimerkki: asiakas etsii tuotetta, sovellus hakee vastaavat tuotteet ja käyttöliittymä näyttää tarjouksen, joka linkittää oikeaan kohteeseen.
Tämä on havainnollistava kulku, ei kuvaus jokaisesta Catalog-integraatiosta. Dokumentoitava toimintamalli voi sen sijaan liittyä taustaprosessiin. Tärkeintä on dokumentoida havaittava käyttäytyminen, ei säilyttää toteutuksen yksityiskohtia, joita kukaan ei tarvitse.
Kerää edustavia syötteitä ja odotettuja tuloksia. Sisällytä haku, joka ei palauta osumia, sekä tuotteita, joilla on useita variantteja. Päätä, mitkä kentät sovellus tarvitsee toimiakseen ja mitkä se voi jättää pois ketään harhaanjohtamatta.
Erota välttämätön työ houkuttelevista lisäyksistä
Aikapaineessa tehtävä migraatio ei ole oikea hetki esitellä uutta suositusstrategiaa. Säilytä vaadittu toiminnallisuus ensin. Siirrä valinnaiset parannukset erilliseen julkaisuun, ellei korvaava ratkaisu tee niistä välttämättömiä.
Jos se on käytännöllistä, sijoittaisimme toimittajakohtaiset kutsut pienen adapterin taakse. Se antaa muun sovelluksen käyttää vakaata sisäistä muotoa. Se vaatii hieman enemmän työtä nyt, joten jätä monimutkaiset abstraktiot väliin kokeiluissa, jotka joka tapauksessa poistetaan käytöstä. Ylläpidettävän tuotantopalvelun kohdalla erottelu on yleensä harkitsemisen arvoista.
Käytä hintapäivitystä regressiotestinä
Erillinen 9. lokakuuta tehty muutos tekee hintojen käsittelystä erityisen ajankohtaisen. Shopifyn Catalog API -päivitys sanoo, että kauppiaan "vertaa hintaan" -hinta voi näkyä valinnaisessa varianttikentässä list_price. Nykyinen price-kenttä ei muutu.
Shopifyn mukaan list_price käyttää samaa Price-objektia kuin price, sisältäen määrän valuutan pienimmissä yksiköissä sekä valuutan. Tuotteet palauttavat myös list_price_range-kentän, joka sisältää tuotteen varianttien alimman ja ylimmän list_price-arvon. Kenttä on osa UCP-luettelomäärittelyä, versio 2026-08-25.
Shopifyn kehittäjädokumentaatio sanoo, että list_price palautetaan vain, kun kauppias jakaa "vertaa hintaan" -hinnat Catalog Mappingin kautta, "vertaa hintaan" -hinta on korkeampi kuin ostajan kontekstissa oleva hinta ja kauppias näyttää nämä hinnat ostajan alueella. ETA-alueen ostajien kohdalla kenttää ei palauteta, jos kauppa piilottaa "vertaa hintaan" -hinnat kyseisellä alueella.
Kauppiaille tämä on syy tarkistaa julkaistavat viitehinnat. Kehittäjille se on hyödyllinen regressiotesti migraation aikana. Se on erillinen päivitys, ja Shopify kertoo, ettei uusi kenttä itsessään vaadi toimenpiteitä. Älä sekoita sitä pakolliseen poistumiseen.
-
Puuttuva
list_price: Shopify sanoo, että puuttuva kenttä tarkoittaa, ettei kyseiselle ostajalle ja konfiguraatiolle palauteta "vertaa hintaan" -hintaa. Älä tee enempää oletuksia tarkistamatta kontekstia. - Määrän muotoilu: Tulkitse summat oikein kyseisen valuutan pienimpien yksiköiden mukaan. Älä käytä universaalia desimaalimuunnosta tarkistamatta valuutan sääntöjä.
-
Varianttien vastaavuus: Laske näytetty säästö nykyisen hinnan ja saman variantin
list_price-hinnan perusteella samassa valuutassa. - Tuotehintojen vaihteluvälit: Älä yhdistä päätepisteitä eri vaihteluväleistä luodaksesi alennusväitteen, jota mikään yksittäinen variantti ei tue.
Havainnollistavana testinä: variantti, jonka hinta on 800 SEK ja "vertaa hintaan" -hinta 1 000 SEK, on 20 % alennuksessa. Toisen variantin viitehintaa ei voi käyttää nimittäjänä kyseisessä laskelmassa. Julkaistu "vertaa hintaan" -hinta ei myöskään itsessään takaa, että kampanjaväite on paikallisten hintasääntöjen mukainen.
Tee käyttöönotto- ja siirtymäsuunnitelma, joka toimii marraskuun 2. päivän jälkeen
Lokakuun 12. päivänä deadlineen on noin kolme viikkoa. Se riittää hallittuun migraatioon, jos tunnistat omistajan nopeasti. Se jättää vähän tilaa kuun lopussa löydetylle omistamattomalle riippuvuudelle.
Alla olevat päivämäärät ovat suositeltu työaikataulumme, eivät ylimääräisiä Shopifyn deadlineja.
14. lokakuuta mennessä: viimeistele riippuvuuskatsaus
Vahvista, mitkä palvelut ovat muutoksen alaisia ja määritä jokaiselle omistaja. Jos toimittaja ei vielä pysty vahvistamaan, käyttääkö se poistuvaa rajapintaa, merkitse kyseinen riippuvuus ratkaisemattomaksi. Hiljaisuus ei ole todiste turvallisuudesta.
21. lokakuuta mennessä: osoita korvaavan ratkaisun toimivuus
Aja korvaava ratkaisu edustavien kulkujen läpi muussa kuin tuotantoympäristössä. Vertaa liiketoiminnan lopputuloksia sen sijaan, että vaatisit identtisiä vastausrakenteita. Kirjaa puuttuvat ominaisuudet riittävän ajoissa varasuunnitelman valitsemiseksi.
28. lokakuuta mennessä: siirrä tuotantoliikenne
Jätä puskuri ennen sammutusta. Seuraa pyyntöjen onnistumisasteita ja vastausaikoja, ja tarkista sitten asiakasrajapinnan tulos. Onnistunut verkkokutsu ei riitä, jos käyttöliittymä näyttää väärän variantin tai ei pysty avaamaan oikeaa tuotetta.
Ennen 2. marraskuuta: poista vanha riippuvuus
Tarkista liikenne ja ajastetut tehtävät uudelleen. Poista käytöstä vanhentuneet polut ja päivitä dokumentaatio. Varmista, että joku vastaa ensimmäisen normaalisuorituksen tarkistamisesta sammutuksen jälkeen.
Sammutuksen jälkeen vanhaan rajapintaan palaaminen ei ole mahdollista. Määritä varasuunnitelma, joka ei tarvitse sitä. Sovelluksesta riippuen tämä voi tarkoittaa valinnaisen tuotehakumoduulin tilapäistä poistamista tai asiakkaiden ohjaamista kaupan olemassa olevaan hakuun. Vältä vanhentuneiden hintojen näyttämistä oletusarvoisena varasuunnitelmana.
Mitä kysyä sovellustoimittajalta ennen hyväksymistä
Toimittajan "tuemme Shopifya" on liian laaja ilmaisu. Kysy, käyttääkö tuotantopalvelu kyseistä rajapintaa, onko korvaava ratkaisu jo käytössä ja mikä todiste osoittaa valmiuden. Pyydä suunniteltua käyttöönottopäivää, jos työtä on vielä jäljellä.
Maksullisen työkalun kohdalla kysyisimme myös, mitä asiakkaat kokevat, kun korvaava ratkaisu ei ole saatavilla. Se on kohtuullinen ostopäätöksen kriteeri: hyödyllisellä sovelluksella tulisi olla ymmärrettävä virhekäsittely. Pienten kauppiaiden ei pitäisi joutua kartoittamaan toimittajan infrastruktuuria selvittääkseen, katoaako tuotepaneeli.
Sulje ongelma vasta, kun on näyttöä: joko palvelu ei kutsu poistuvaa rajapintaa, tai korvaava ratkaisu toimii tuotannossa ja vanhat kutsut ovat loppuneet. Valmis koodimuutos, jota ei ole otettu käyttöön, jättää riskin juuri siihen, missä se oli.
Yhteenveto
- Global Catalog REST API lakkaa palvelemasta liikennettä 2. marraskuuta 2026. Vahvista, riippuuko toimintasi siitä, ennen kuin tilaat muutostöitä.
- Siirrä muutoksen piiriin kuuluvat integraatiot Global Catalog MCP -rajapintaan ja testaa toiminnallisuus, johon asiakkaat tai henkilökunta luottavat.
- Sisällytä valinnaiset "vertaa hintaan" -hinnat ja varianttitason määränkäsittely regressiotesteihin.
- Suorita käyttöönotto ennen deadlinea ja valitse varasuunnitelma, joka ei riipu poistetusta rajapinnasta.
Lähteet
- Global Catalog REST API stops serving traffic on November 2, 2026
- Catalog API now returns compare-at prices as
list_price
Haluatko meidän hoitavan asian?
Olemme Shopify Premier -toimisto, ja tämä on jokapäiväistä työtämme: suorituskyky, konversio-optimointi (CRO) ja tuloksiin keskittyvä kauppojen rakentaminen. Varaa ilmainen kauppakatselmus, niin näytämme kolme muutosta, jotka tekisimme ensimmäisenä.
Usein kysyttyjä kysymyksiä
Milloin Shopifyn Global Catalog REST API lakkaa toimimasta?
Shopifyn mukaan Global Catalog REST API lakkaa palvelemasta liikennettä 2. marraskuuta 2026. Se merkittiin vanhentuneeksi huhtikuussa 2026. Niiden sovellusten, joita muutos koskee, on migroitava ennen sammutusta.
Tarvitseeko jokaisen Shopify-kaupan migroida Global Catalog API -rajapinnasta?
Ei. Tiedote koskee sovelluksia, jotka kutsuvat Global Catalog REST API -rajapintaa. Pyydä kehittäjiäsi ja sovellustoimittajiasi tarkistamaan, käyttääkö jokin tuotantopalvelu tai ajastettu tehtävä sitä.
Mikä korvaa Shopifyn Global Catalog REST API -rajapinnan?
Shopify nimeää Universal Commerce Protocol -protokollaa toteuttavan Global Catalog MCP:n korvaajaksi. Kehittäjien tulisi tarkistaa sen nykyiset vaatimukset ja tuetut toiminnot sen sijaan, että olettaisivat migraation olevan vain URL-osoitteen muutos.
Mitä list_price tarkoittaa Shopifyn luettelossa?
list_price on valinnainen varianttikenttä kauppiaan "vertaa hintaan" -hinnalle. Se käyttää Price-objektia, jossa on määrä valuutan pienimmissä yksiköissä ja valuutta. Nykyinen price-kenttä on muuttumaton. Shopify palauttaa kentän vain, kun ostajan kontekstia ja kauppiaan asetuksia koskevat ehdot täyttyvät.
Voiko sovellus palata vanhaan Global Catalog REST API -rajapintaan marraskuun 2. päivän jälkeen?
Ei. Se ei ole toimiva varasuunnitelma sen jälkeen, kun rajapinta on lakannut palvelemasta liikennettä. Suunnittele joko supistettu käyttökokemus tai muu tuettu polku, joka ei riipu poistetusta palvelusta.
