Shopify elimină interogarea automaticDiscounts din GraphQL Admin API începând cu versiunea 2027-01. Aplicațiile care citesc reduceri automate prin ea trebuie migrate la discountNodes cu filtrul query: "method:automatic", altfel upgrade-ul produce eroare de validare. Aplicațiile pe 2026-10 sau mai vechi rămân funcționale cât timp versiunile sunt suportate.

Concret, schimbarea a fost anunțată în changelog-ul Shopify pe 18.09.2026 (sursa) și face parte din ciclul normal de curățare a API-ului. Nu e o surpriză, e o deprecation dusă până la capăt. Întrebarea reală pentru echipele de ecommerce și martech din România nu e "ce s-a schimbat", ci "cât de repede putem elimina dependența din cod și din integrările pe care le folosim zilnic".

Ce se schimbă efectiv în GraphQL Admin API

Din versiunea 2027-01, automaticDiscounts dispare complet din QueryRoot. Orice request care include interogarea pe 2027-01 nu mai întoarce date, ci o eroare de validare. În plus, tipurile DiscountAutomaticConnection și DiscountAutomaticEdge sunt eliminate, pentru că niciun alt câmp din schemă nu le mai returnează.

Înlocuirea recomandată este discountNodes, cu query: "method:automatic". Returnează o conexiune de obiecte DiscountNode, iar reducerea în sine stă pe câmpul discount. Filtrele sunt similare cu cele de dinainte: status, discount_type, discount_class, created_at, starts_at. Fragmentarea inline se mută un nivel mai adânc, pe discount.

Un detaliu care merită subliniat: și automaticDiscountNodes este depreciată în favoarea discountNodes. Dacă migrezi acum pe automaticDiscountNodes, vei migra din nou mai târziu. E o capcană clasică de "rezolv rapid acum", care îți creează datorie tehnică peste două trimestre.

Cine e afectat și cine poate dormi liniștit

Afectate sunt aplicațiile care apelează automaticDiscounts și cer versiunea 2027-01 sau mai nouă, inclusiv cele pinned pe unstable din momentul în care 2027-01 devine ultima versiune. Afectate sunt și tooling-ul și tipurile generate care referențiază DiscountAutomaticConnection sau DiscountAutomaticEdge.

Neafectate rămân aplicațiile care cer 2026-10 sau mai vechi, atât timp cât versiunile respective sunt suportate. Cele care citesc deja reduceri automate prin discountNodes nu au nimic de modificat. Cele care folosesc automaticDiscountNodes nu sunt atinse de această eliminare specifică, dar ar trebui să planifice trecerea la discountNodes.

Dacă aplicația ta nu apelează automaticDiscounts, nu ai nicio acțiune de făcut pentru această schimbare.

De ce contează din perspectiva datelor de marketing

discountNodes unifică toate reducerile, automate și bazate pe cod, într-o singură suprafață de interogare. Același vocabular de filtrare, același pattern de paginare. Pentru cine construiește rapoarte de performanță, asta înseamnă mai puțin cod de lipit între rezultate separate și mai puține locuri unde apar discrepanțe de numărare.

Aici e partea relevantă pentru un marketer care se uită la contribuția promoțiilor în ROAS sau în MER. Dacă pipeline-ul tău de date citea reducerile automate printr-o interogare, iar raportarea pe cod prin alta, aveai două surse care puteau raporta diferit. Un singur query reduce riscul de dublă numărare sau de perioade lipsă în dashboard.

Merită spus clar: nu avem date că această schimbare afectează CPA, vânzările sau bugetele. Este o schimbare de infrastructură API. Efectele apar doar dacă integrarea se rupe și raportarea tace câteva zile fără să observi.

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

Dacă ai un magazin Shopify și folosești doar aplicații din App Store, probabil nu atingi direct acest cod. Problema apare la nivel de furnizor: aplicația de reduceri, loialitate sau atribuire pe care o plătești lunar trebuie să fi migrat înainte de upgrade. Dacă furnizorul întârzie, poți rămâne blocat pe o versiune veche de API sau, mai rău, să pierzi sincronizarea promoțiilor în rapoarte.

Dacă ai dezvoltator intern sau o agenție care ți-a construit integrări custom, întrebarea de pus este simplă: folosim automaticDiscounts undeva în cod sau în tipurile generate? Dacă da, există un ticket cu termen? Dacă nu, cine confirmă?

Pentru echipele care rulează campanii pe bază de promoții automate, testele A/B pe oferte sau rapoarte de marjă pe perioade promoționale, întreruperea citirii reducerilor automate nu oprește vânzarea, dar oprește vizibilitatea. Iar decizia luată pe date lipsă e mai scumpă decât migrarea.

Aici se leagă de discuția mai largă despre disciplina de date în platforme: același tip de rigorere o vezi în analiza despre audit trail-ul pentru prețurile contextuale, unde trasabilitatea schimbărilor devine parte din operare, nu un bonus.

Ce verifici concret, în ordine

Pașii propuși mai jos sunt recomandări, nu constatări din sursă.

  1. Caută în codebase automaticDiscounts, DiscountAutomaticConnection și DiscountAutomaticEdge, inclusiv în tipurile GraphQL generate și în snapshot-urile de schemă.
  2. Verifică ce versiune de API cer aplicațiile tale, atât cele interne cât și integrările terțe.
  3. Confirmă cu furnizorii de aplicații statutul migrării. O întrebare scurtă prin email sau chat rezolvă incertitudinea.
  4. Înlocuiește interogarea cu discountNodes și query: "method:automatic", mutând fragmentele inline pe câmpul discount.
  5. Regenerează tipurile împotriva versiunii 2027-01, astfel încât forma datelor să corespundă.
  6. Testează într-un development store pe 2027-01 și compară rezultatul cu ce returna aplicația pe 2026-10.
  7. Dacă nu poți migra la timp, rămâi pe 2026-10 sau o versiune suportată anterioară până termini schimbarea.

Un punct de onestitate metodologică: o căutare care nu găsește automaticDiscounts în cod nu dovedește automat că nimic nu depinde de ea. Poate fi în dependențe, în tooling de build sau în cod generat. Verificarea incompletă nu e dovadă de absență.

Limite, scenarii ipotetice și ce nu știm încă

Sursele publice nu spun cât de răspândită este utilizarea automaticDiscounts în rândul aplicațiilor. Nu avem date despre câte integrări din piața românească sunt afectate. Nu avem date despre cât durează o migrare tipică.

Ipotetic, dacă un raport săptămânal de promoții se bazează pe o integrare care nu a migrat, iar upgrade-ul se face forțat, atunci o săptămână de raportare poate veni incompletă. Nu pentru că s-a vândut mai puțin, ci pentru că datele nu s-au citit. Asta e o ipoteză de lucru, nu un rezultat măsurat.

Al doilea scenariu, la fel de ipotetic: dacă echipa migrează pe automaticDiscountNodes în loc de discountNodes, câștigă timp scurt și plătește din nou mai târziu. Alegerea rațională e saltul direct la discountNodes.

În ambele cazuri, recomandarea este aceeași: verifică, nu presupune. Iar dacă probele sunt insuficiente în codul tău sau în răspunsul unui furnizor, cere confirmare scrisă înainte de upgrade.

FAQ

Trebuie să fac ceva dacă magazinul meu folosește doar aplicații din App Store? Direct, nu. Indirect, da: întreabă furnizorii aplicațiilor de reduceri și loialitate dacă au migrat la discountNodes. Dacă nu, upgrade-ul lor la 2027-01 poate întârzia, iar sincronizarea promoțiilor tale poate fi afectată temporar.

Pot rămâne pe 2026-10? Da, aplicațiile care cer 2026-10 sau mai vechi continuă să funcționeze atât timp cât versiunile respective sunt suportate. Este o soluție de tranziție, nu una permanentă. Planifică migrarea înainte ca versiunea să iasă din suport.

Care e diferența dintre discountNodes și automaticDiscountNodes? discountNodes citește toate reducerile, automate și bazate pe cod, cu un singur vocabular de filtrare. automaticDiscountNodes este depreciată în favoarea discountNodes. Dacă migrezi pe ea, vei face a doua migrare mai târziu.

Concluzia ALLSoft Agency

Unelte AI pot accelera analiza aici: căutarea referințelor în cod, maparea tipurilor generate, schițarea interogării noi, pregătirea listei de verificare. Dar decizia și execuția rămân umane. Media buyer-ul sau dezvoltatorul știe ce rapoarte contează pentru business, ce promoții sunt critice și ce se rupe dacă datele lipsesc o săptămână.

Pasul concret îl face ALLSoft Agency: verificăm dependențele de API din integrările tale Shopify, prioritizăm migrarea după impactul real asupra raportării și o executăm fără să întrerupem operațiunea curentă. Fără hype, fără cifre inventate, doar lucrul făcut corect înainte să te prindă termenul.