Shopify a adăugat în GraphQL Admin API versiunea 2026-10 câmpuri pentru interogarea și parcurgerea ierarhiei de piețe a unui magazin, potrivit changelog-ului publicat de platformă (sursa). Practic, aplicațiile care au scope-ul read_markets pot cere direct relațiile părinte-copil dintre piețe, în loc să le deducă din condiții de piață sau din starea de customizare. Pentru magazinele existente nu e necesară nicio acțiune imediată.

Ce s-a schimbat, concret

Sursa spune că interogarea nouă marketRelationships returnează o conexiune de obiecte MarketRelationship. Fiecare relație conține un childMarket și un parentMarket care poate fi nul. Dacă parentMarket e nul, înseamnă că piața respectivă este rădăcină.

În plus, obiectul Market primește patru câmpuri noi: parentMarkets, parentMarketsCount, childMarkets și childMarketsCount. Adică poți cere atât lista părinților direcți, cât și numărul lor, la fel pentru copii.

Un detaliu important din sursă: ID-urile relațiilor rămân stabile atunci când Shopify reconstruiește datele, atât timp cât relația directă există și după reconstrucție. În schimb, cursorii de paginare se pot schimba în timpul unei reconstrucții, deci paginarea trebuie reluată după ce detectezi o schimbare.

Reconstrucția relațiilor se face asincron după modificarea ierarhiei. Interogarea marketRelationshipsStatus returnează o valoare de versiune opacă pe care o compari cu cea citită anterior. Dacă valoarea s-a schimbat, relațiile materializate au avansat.

Sursa dă și o recomandare de ordine: citește versiunea înainte de a face o modificare care afectează ierarhia, verifică-o periodic în cereri separate și recitește relațiile după ce valoarea se schimbă. Și un avertisment clar: nu trata versiunea citită în aceeași cerere cu marketRelationships ca pe un identificator de snapshot.

Cine e afectat: aplicațiile pe GraphQL Admin API 2026-10 sau mai nou, care trebuie să inspecteze sau să parcurgă relațiile dintre piețe. Aplicațiile pe versiuni anterioare nu pot interoga câmpurile noi, iar cele care nu interoghează piețe nu sunt afectate.

Atât despre sursă. De aici încolo e analiză și recomandare, nu fapte din changelog.

De ce contează pentru echipele de ecommerce

Până acum, dacă voiai să reconstruiești structura de piețe a unui magazin, o făceai indirect. Te uitai la condiții de piață, la starea de customizare, la alte semnale. Asta însemna cod fragil, care se strica la fiecare schimbare de logică internă și care presupunea presupuneri. Lucrul ăsta se vede în timpul de dezvoltare și în frecvența incidentelor, nu neapărat în factură.

Acum ai un grafic direct: cine e părinte, cine e copil, câte legături are fiecare nod. Pentru un integrator sau pentru echipa internă de un magazin mediu spre mare, asta schimbă felul în care construiești raportarea.

Gândește-te la un magazin care vinde în 15 piețe, cu sub-piețe pe regiuni și setări diferite de preț, monedă sau catalog. Dacă vrei un raport de performanță care respectă ierarhia reală, nu una presupusă, aveai nevoie de o hartă. Acum harta o iei din API.

Partea de asincronizare e cea care merită respectată cu strictețe. Mulți integratori tratează citirile de API ca pe un snapshot instantaneu. Aici nu merge. Modifici ierarhia, aștepți reconstrucția, apoi recitești. Dacă nu respecți ordinea, raportezi pe date vechi și tragi concluzii greșite despre ce se întâmplă în piețele tale.

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

Ai un magazin Shopify care vinde și în afara României, cu mai multe piețe configurate. Întrebarea ta nu e "ce e un MarketRelationship". Întrebarea ta e dacă datele din dashboard-uri și din rapoartele tale reflectă structura reală a piețelor.

Primul lucru de verificat: ce se întâmplă sub capotă la magazinul tău. Ai un ERP, un middleware de feed-uri, un tool de raportare care citește piețele? Dacă da, întreabă furnizorul pe ce versiune de API rulează și dacă folosește read_markets. Nu presupune. O verificare incompletă nu dovedește că totul funcționează, la fel cum nu dovedește nici că ceva e stricat.

Al doilea lucru: cine din echipă schimbă ierarhia de piețe și cu ce frecvență. Dacă e o persoană care adaugă o sub-piață o dată la trei luni, riscul de a citi date vechi e mic. Dacă ai automatizări care ating configurația de piețe, atunci orice raport care depinde de ierarhie trebuie să țină cont de reconstrucția asincronă.

Al treilea: costurile. Nu în bani, ci în timpul pierdut. Un raport construit pe o ierarhie presupusă greșit îți poate trimite bugetul spre piața care nu are nevoie de el. Asta nu înseamnă că s-a întâmplat, înseamnă că e o clasă de risc pe care o poți elimina. Verifică structura înainte să optimizezi pe ea.

Un magazin românesc care vinde în UE și în afara UE are de obicei piețe separate pe monedă și pe condiții de livrare. Dacă sub-piețele nu sunt mapate cum trebuie în raportare, compari mereu mere cu pere. Câmpurile noi nu rezolvă problema singure, dar îți dau baza corectă pe care poți construi.

Aici se leagă și de discuția despre măsurare pe care o avem în analiza despre Google Ads multi-source conversions beta: datele de intrare trebuie să fie corecte la nivel de structură înainte să tragi concluzii la nivel de canal. Dacă baza e greșită, optimizarea de sus doar amplifică eroarea.

Ce aș cere eu unui integrator înainte să aprob orice

Întrebările pe care le pun sunt simple și incomode.

Ce versiune de API folosești pentru piețe? Când ai citit ultima dată ierarhia, ai citit versiunea de status înainte de modificare sau după? Cum detectezi că datele s-au schimbat și ce faci în intervalul dintre modificare și reconstrucție? Ce se întâmplă cu paginarea dacă cursorii se schimbă la mijloc?

Nu toate au răspuns într-un changelog. Changelogul îți spune ce e posibil, nu ce ai tu implementat. Verificarea e munca ta sau a furnizorului tău.

Recomandarea mea concretă, ca pas următor, nu ca promisiune de rezultat:

  1. Identifică toate sistemele care citesc piețe din Shopify: raportare, feed-uri, ERP, tool-uri de preț.
  2. Cere furnizorilor versiunea de API și scope-urile folosite.
  3. Dacă vreunul schimbă ierarhia automat, cere-i să documenteze fluxul: citește versiune, modifică, sondează, recitește.
  4. Testează pe un magazin de staging, nu pe producție.
  5. Abia apoi decide dacă ai nevoie de vreo schimbare.

Dacă niciun răspuns nu vine clar, nu înseamnă că e o problemă. Înseamnă că nu ai suficiente probe ca să te pronunți într-un sens sau altul. Așa arată o verificare corectă.

Limite și scenarii ipotetice

Ce nu spune sursa și nu trebuie să inventăm: nu știm cât durează reconstrucția în practică, nu știm dacă toate tipurile de modificări declanșează reconstrucție egală ca timp, nu știm dacă integratorii din piață au adoptat deja versiunea 2026-10.

Scenariu ipotetic: un magazin cu sub-piețe pe regiuni schimbă structura în timpul unei campanzi. Dacă raportul citește ierarhia în fereastra de reconstrucție, poate afișa date vechi câteva cicluri. Nu e o pierdere garantată, e o fereastră de risc pentru decizii luate pe cifre. Se elimină dacă fluxul respectă ordinea din documentație.

Un alt scenariu: un tool de raportare care a construit ierarhia prin inferență din condiții de piață. Dacă trece pe câmpurile noi, e posibil să vadă diferențe față de ce raporta înainte. Nu înseamnă neapărat că datele vechi erau greșite peste tot, înseamnă că trebuie reconciliate înainte să schimbi dashboard-uri.

Aici vezi și de ce contează să nu amesteci viteza AI cu procesele lente, subiect pe care l-am tratat în AI rapid pe procese lente: un API nou e viteza. Verificarea structurii magazinului tău e procesul lent care decide dacă viteza aia produce ceva util.

FAQ

Trebuie să fac ceva dacă am un magazin Shopify obișnuit? Nu. Sursa spune explicit că nu e necesară nicio acțiune pentru aplicațiile existente, iar integrările vechi continuă să funcționeze pe versiunile anterioare de API. Dacă nu ai integrare care citește piețe, schimbarea te privește doar indirect.

Pot interoga câmpurile noi dacă rulez pe o versiune mai veche de API? Nu. Aplicațiile care folosesc versiuni anterioare lui 2026-10 nu pot interoga câmpurile noi. Ai nevoie de versiunea 2026-10 sau mai nouă și de scope-ul read_markets.

De ce e importantă valoarea de versiune din marketRelationshipsStatus? Pentru că relațiile se reconstruiesc asincron. Dacă faci o modificare de ierarhie și recitești imediat, poți primi date vechi. Compari versiunea citită înainte cu cea de după și recitești relațiile abia când valoarea s-a schimbat.

Cursul paginării rămâne valid după o reconstrucție? Nu garantat. Sursa spune că ID-urile relațiilor rămân stabile cât timp relația directă există, dar cursorii de paginare se pot schimba. Recomandarea e să reiei paginarea de la început după ce detectezi o schimbare de versiune.

Concluzia ALLSoft

Un API nou nu mută singur cifrele dintr-un cont. Îți dă date mai curate despre structura magazinului, iar asta e util doar dacă cineva le folosește cu cap. AI-ul ajută la analiză și la planning: mapează ierarhii, compară versiuni, semnalează unde datele nu se leagă. Dar decizia și execuția rămân umane: media buyer-ul care știe ce piață merită buget, cine validează fluxul tehnic și cine își asumă că raportul reflectă realitatea.

Pasul concret îl face ALLSoft Agency: ne uităm la structura de piețe, la ce citesc sistemele tale și la ce decizii iei pe baza lor. Fără hype, fără promisiuni de cifre, doar verificare pe probe.