Global Catalog REST API, deprecat din aprilie 2026, nu mai servește trafic pe 2 noiembrie 2026. Aplicațiile Shopify care încă îl apelează trebuie migrate la Global Catalog MCP, bazat pe Universal Commerce Protocol, înainte de această dată, altfel toate cererile către endpoint-urile vechi vor eșua, inclusiv cele pe cataloage salvate.

Anunțul vine din changelogul Shopify, publicat pe 9 octombrie 2026, și e unul dintre acele update-uri pe care majoritatea marketerilor le citesc pe diagonală și le plătesc doi ani mai târziu. Nu e o schimbare de design, nu e un feature nou. E o închidere de infrastructură. Iar dacă ai un app, un feed aggregator sau un instrument intern care trage produse din catalogul global Shopify, data de 2 noiembrie 2026 e un termen real, nu o sugestie.

Ce se schimbă exact pe 2 noiembrie 2026

Situația e simplă, fără nuanțe de interpretare. În aprilie 2026, Shopify a deprecat Global Catalog REST API și l-a înlocuit cu Global Catalog MCP. Deprecarea a fost anunțată, dar API-ul a continuat să funcționeze. Pe 2 noiembrie 2026, acest lucru se termină. Toate cererile către https://discover.shopifyapps.com/global/... vor eșua, inclusiv cele pe cataloagele salvate.

Lista endpoint-urilor afectate, așa cum apare în sursă, este scurtă și explicită: GET /global/v2/search pentru căutare, GET /global/v2/p/{upid} pentru produs după identificator, GET /global/v2/p/by-variant/{vid} pentru variantă, și POST /global/v2/lookup pentru lookup în lot. Dacă vreunul dintre aceste patru apeluri există în codul tău, în vreun cron, în vreun webhook intern, în vreun script uitat de un contractor acum un an, ești în zona de risc.

Noul punct de intrare este https://catalog.shopify.com/api/ucp/mcp și expune trei unelte UCP: search_catalog, lookup_catalog și get_product. Traducerea este mecanică: Search devine search_catalog, Lookup devine get_product, Bulk lookup devine lookup_catalog. Dacă folosești un catalog salvat, nu mai passezi un URL de endpoint, ci un identificator catalog.catalog_id.

Autentificarea nu se schimbă. Continui să generezi bearer tokens din credențialele clientului din Dev Dashboard. În schimb, apare un câmp nou de context: meta.ucp-agent.profile, cu URL-ul profilului tău de agent, trimis în fiecare cerere. Și schemele de request și response se schimbă, ceea ce înseamnă că adaptarea nu e doar un find and replace pe URL.

De ce contează asta pentru ecommerce, nu doar pentru developeri

Sunt tentat să spun că e o știre tehnică și să o las acolo. Nu e. E o știre de marketing, pentru un motiv simplu: catalogul global Shopify alimentează o categorie întreagă de produse digitale care vând. Aplicații de discovery, comparatoare de prețuri, instrumente de sourcing pentru dropshipping, agenți AI care răspund la întrebarea "unde găsesc produsul X la prețul Y". Toate acestea depind de un strat de date care acum se mută de pe REST pe MCP.

Iar mutarea din REST în MCP nu e cosmetică. MCP înseamnă Model Context Protocol, adică un protocol gândit pentru agenți AI, nu pentru integrări clasice. Shopify nu mută traficul dintr-un API în altul din plictiseală. O face pentru că direcția este ca asistenții AI să poată interoga direct catalogul, cu context de cumpărător, filtre, paginare și semnale de disponibilitate. Cine construiește astăzi pe REST construiește pe un strat care nu mai e ținta de investiție.

Aici e legătura cu tema mai largă a vizibilității în AI Search. Dacă produsele tale ajung în răspunsurile unui asistent AI prin intermediul unui catalog global, atunci felul în care acel catalog e interogat determină dacă apari sau nu. Merită citit în paralel cu discuția despre cum arată SEO-ul și GEO-ul în 2026, pentru că logica se repetă: nu optimizezi pentru un motor, optimizezi pentru un strat de interogare care se schimbă mai repede decât tine.

Un al doilea unghi, mai practic: dacă ai un feed de produse care alimentează reclame, iar acel feed se bazează pe un app care folosește REST API-ul vechi, atunci pe 3 noiembrie 2026 s-ar putea să te trezești cu un feed gol și cu campanii care rulează pe date vechi. Nu pentru că cineva a greșit ceva intenționat, ci pentru că un termen dintr-un changelog a trecut neobservat. Când pică un feed, efectul nu e imediat, este întârziat și greu de atribuit. Exact genul de problemă care consumă buget.

Cum arată migrarea, pas cu pas

Nu există scurtătură. Pașii sunt următorii, așa cum reiese din materialul sursă:

  1. Inventariază apelurile. Caută în cod toate referințele la discover.shopifyapps.com/global/. Include cron-uri, job-uri de fundal și integrări făcute de terți.
  2. Mapează fiecare apel pe unealta UCP corespunzătoare. Search pe search_catalog. Lookup pe produs sau variantă pe get_product, cu identificatori de tip gid://shopify/p/{upid} sau gid://shopify/ProductVariant/{id}. Bulk lookup pe lookup_catalog.
  3. Schimbă endpoint-ul pe catalog.shopify.com/api/ucp/mcp.
  4. Adaugă meta.ucp-agent.profile în fiecare cerere, cu URL-ul profilului de agent.
  5. Dacă folosești cataloage salvate, treci de la URL de endpoint la catalog.catalog_id.
  6. Actualizează schemele de request și response la cele UCP. Aici se rupe cel mai des, pentru că structura de răspuns nu e identică.
  7. Testează înainte de a migra, folosind Shopify AI Toolkit sau UCP CLI, cu comanda ucp catalog search.
  8. Rulează ambele variante în paralel o perioadă, dacă ai timp, și compară rezultatele înainte de a șterge codul vechi.

Pasul 7 este cel pe care îl sărează majoritatea. Este și cel mai ieftin. O oră de test local economisește zile de debugging în producție.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un magazin pe Shopify și nu ai construit nimic custom, probabil nu ești afectat direct. API-ul global e un strat pentru aplicații, nu pentru teme. Dar afectarea indirectă e mai probabilă decât crezi.

Scenariul tipic: ai instalat acum un an sau doi un app de discovery, comparare sau sincronizare de catalog. App-ul funcționează, tu nu te-ai uitat la el de luni de zile. Pe 2 noiembrie 2026, dacă dezvoltatorul acelui app nu a migrat, funcția moare tăcut. Nu primești eroare vizibilă în admin. Pur și simplu recomandările dispar, iar tu observi abia când scade conversia și nu înțelegi de ce.

Ce poți face concret, ca om de marketing și nu ca developer:

Pentru un magazin român care vinde pe piața locală, expunerea e mică, dar nu zero. Pentru cine operează cross-border sau listează produse în agregatoare internaționale, expunerea e reală. Iar costul unei zile de feed mort se vede în CPA imediat.

Dacă lucrezi cu feed-uri și retargeting, merită să te uiți și la practicile de abandoned cart care chiar reduc pierderile, pentru că ambele teme au același nod: un strat de date care se rupe tăcut și o echipă de marketing care află prea târziu.

Ce rămâne neclar și ce ar trebui verificat

Materialul sursă nu spune nimic despre costuri, despre limite de rată la MCP, despre perioade de grație sau despre ce se întâmplă cu aplicațiile care ratează termenul. Nu presupunem. Dacă cineva îți spune că știe exact ce se întâmplă pe 3 noiembrie cu un app nemigrat, cere-i sursa.

De asemenea, nu e clar cât de răspândit este API-ul în ecosistemul de aplicații. Changelogul nu furnizează cifre de adopție, nici pentru REST, nici pentru MCP. Asta înseamnă că nu putem estima câte app-uri din piață vor pica. Putem doar să presupunem că cele care nu au comunicat nimic clienților sunt mai expuse.

Un al treilea punct de verificat: dacă unii furnizori migrează, dar cu un interval de câteva săptămâni după termen. Practic, o zonă gri în care clientul nu știe dacă e acoperit. Recomandarea este să ceri confirmare scrisă a datei de migrare, nu a intenției de a migra.

FAQ

Cine este afectat de oprirea Global Catalog REST API pe 2 noiembrie 2026? Orice aplicație sau script care apelează endpoint-urile discover.shopifyapps.com/global/..., inclusiv cererile pe cataloage salvate. Magazinele care nu au integrări custom nu sunt afectate direct, dar pot fi afectate indirect prin app-uri terțe nemigrate.

Mai pot folosi autentificarea existentă după migrare? Da. Surse verificată indică faptul că autentificarea nu se schimbă. Continui să generezi bearer tokens din credențialele clientului din Dev Dashboard. Ce se schimbă este endpoint-ul, schemele de request și response, plus câmpul meta.ucp-agent.profile care trebuie inclus în fiecare cerere.

Cum testez înainte să migrez? Shopify pune la dispoziție AI Toolkit și UCP CLI, iar sursa menționează comanda ucp catalog search pentru testarea uneltelor înainte de migrare. Testarea locală este cea mai ieftină formă de a evita o pană în producție.

Concluzia ALLSoft

AI-ul ajută aici, dar nu decide nimic. Un model poate citi changelogul, poate mapa cele patru endpoint-uri REST pe cele trei unelte UCP, poate genera un plan de migrare și poate scrie teste de comparație între răspunsurile vechi și cele noi. Poate, de asemenea, să scaneze un depozit de cod după apeluri către discover.shopifyapps.com și să scoată la iveală integrări uitate.

Ce nu face AI-ul: nu îți spune dacă acel app de discovery merită păstrat, nu decide dacă riști să pierzi vânzări sau nu, nu sună furnizorul și nu îi cere confirmare scrisă. Execuția rămâne umană, iar media buyer-ul rămâne cel care știe ce se întâmplă cu CPA-ul când un feed cade.

Dacă vrei să verifici dacă setup-ul tău e expus la termenul din 2 noiembrie 2026 și să pui la punct un plan de migrare fără să blochezi campaniile, echipa ALLSoft Agency poate face auditul și pașii de execuție. Fără hype, fără promisiuni de cifre. Doar inventar, termene și test pe 3 noiembrie.