Shopify a anunțat că limita de complexitate a interogărilor pentru abonamentele Events scade de la 250 la 100 de puncte. Modificarea nu afectează Classic Webhooks. Fiecare interogare primește un scor calculat după câmpurile selectate, tipurile de date returnate și numărul de elemente cerute prin first sau last. Abonamentele care depășesc noul prag trebuie revizuite și rearanjate astfel încât fiecare interogare să rămână sub 100 de puncte.

Ce se schimbă concret și de ce contează

Vestea vine din changelog-ul Shopify, publicat pe 22.09.2026, și este o modificare de infrastructură, nu o funcție nouă de marketing. Subiectul sună tehnic, dar miza este operațională: abonamentele Events sunt mecanismul prin care o aplicație sau un sistem intern află că s-a întâmplat ceva în magazin, de la o schimbare de preț la un produs nou sau la o modificare de stoc.

Până acum, limita era de 250 de puncte pe interogare. De la anunț, plafonul scade la 100. Scorul nu este arbitrar: Shopify îl calculează după modelul de cost GraphQL, adică numără câmpurile selectate, complexitatea tipurilor returnate și câte elemente ceri într-o conexiune atunci când folosești first sau last. Cu cât ceri mai multe date într-o singură interogare, cu atât scorul crește.

Un detaliu important, care merită subliniat pentru că schimbă calculele echipei tehnice: interogările executate de abonamentele Events nu intră în limita de rate a API-ului aplicației. Practic, nu plătești în buget de requesturi pentru aceste abonamente. Plătești însă în complexitate. Iar complexitatea este acum mai scumpă cu 60 la sută mai puțin spațiu de manevră față de înainte.

Titlul original al anunțului este „Events subscription query complexity limit is changing to 100 points", iar sursa este Shopify Changelog.

Ce trebuie să faci înainte să te lovească problema

Primul pas este auditul. Nu te poți apăra de o limită dacă nu știi unde ești față de ea. Inventariază toate abonamentele Events active, calculează scorul fiecărei interogări și marchează-le pe cele care se apropie sau depășesc 100 de puncte. Cele care stau lejer sub 50 nu îți consumă energie. Cele care depășesc pragul sunt prioritare.

Atenție: dacă o singură interogare nu depășește limita, asta nu înseamnă că sistemul tău este în siguranță. Poate ai cinci abonamente care stau fiecare la 80 de puncte, iar riscul nu e imediat, dar nici confortabil. Marja de eroare se subțiază repede când adaugi un câmp nou.

Al doilea pas este să separi abonamentele după tipul de muncă pe care o fac. Shopify recomandă explicit configurarea mai multor abonamente pentru același subiect, fiecare cu propriile triggere și interogări. Asta nu este o pierdere de performanță, este o disciplină arhitecturală. Un abonament pentru schimbări de preț nu are ce căuta în aceeași interogare cu unul care urmărește titluri de produse.

Al treilea pas este să interoghezi resursa schimbată, nu tot arborele din jurul ei. Exemplul din documentație este clar: pentru o schimbare de preț la o variantă, ceri prețul variantei afectate, SKU-ul și ID-ul produsului părinte, în loc să tragi primele 250 de variante ale produsului. Prima abordare acoperă varianta schimbată chiar dacă aceasta se află dincolo de prima pagină. A doua abordare consumă complexitate degeaba și ratează exact ce te interesa.

Al patrulea pas este să potrivești interogările cu variabilele disponibile. Un trigger de preț de variantă îți dă $variantsId, un trigger de titlu de produs nu. Dacă ai nevoie de variabile diferite, folosește abonamente separate. Amestecul de triggere într-o singură interogare este una dintre cele mai frecvente surse de complexitate inutilă.

Unde se sparge lanțul, în practică

Aici merită să fim transparenți despre limitele oricărei analize pe baza anunțului. Nu știm din sursă care este termenul exact de aplicare a noii limite, nu știm dacă există o perioadă de grație și nu știm cum arată distribuția reală a scorurilor în aplicațiile existente. Acestea sunt întrebări de verificat direct în documentația Shopify, în forumul comunității sau printr-un test controlat în mediul de dezvoltare. O verificare incompletă nu dovedește absența unei funcții, dar nici nu o confirmă.

Ce putem spune cu certitudine este că reducerea pragului forțează o curățenie pe care multe aplicații o amânau. Interogările care funcționau pentru că aveau spațiu la 250 de puncte devin vulnerabile sub 100. Nu este o tragedie, este un prilej de a elimina câmpuri pe care handlerul nu le folosea oricum.

Un scenariu ipotetic util pentru echipele tehnice: o aplicație care sincronizează stocuri între Shopify și un ERP. Dacă interogarea ei trage pentru fiecare eveniment întregul obiect de produs cu variante și metadate, scorul sare lejer de 100. Dacă o rescrii să ceară doar ID-ul variantei, cantitatea și SKU-ul, ajungi sub prag și reduci și traficul de date. Nu am testat acest scenariu, este o construcție logică pe baza regulilor de calcul descrise în anunț.

Ce înseamnă pentru tine

Dacă ești antreprenor sau marketer într-un ecommerce român care folosește Shopify, vei simți această schimbare indirect, nu direct. Tu nu scrii interogări GraphQL. Dar folosești aplicații care o fac: ERP-uri, tool-uri de facturare, integrări de curierat, aplicații de stoc, platforme de loyalty.

Impactul apare sub forma unor erori de sincronizare greu de diagnosticat. O schimbare de preț care nu ajunge la timp în sistemul de facturare. Un stoc care se actualizează cu întârziere. O notificare de comandă care lipsește. Aceste simptome nu vin cu mesajul „limita de complexitate a fost depășită", vin ca discrepanțe pe care le observi abia când clientul se plânge.

Recomandarea practică pentru un antreprenor este să întrebe direct furnizorii aplicațiilor dacă au revizuit abonamentele Events față de noua limită. Este o întrebare simplă, cu răspuns binar: da sau nu. Dacă răspunsul este vag, cere un termen. Aplicațiile care nu răspund la această întrebare în următoarele săptămâni sunt un risc de operare, indiferent cât de frumoasă e interfața lor.

Pentru agențiile care administrează magazine Shopify, discuția se mută pe partea de integrare, nu pe partea de reclame. Dar disciplina de a ceri doar datele de care ai nevoie este aceeași pe care o aplici în Google Ads când construiești segmente prea largi, o temă pe care am atins-o în analiza despre testul de buget vs. target CPA și ROAS. Prea mult input, costuri mari, semnal slab. Și în GraphQL, și în media buying, logica se repetă.

Cum arată un plan de lucru sănătos

Pașii pe care îi propunem, marcați explicit ca recomandare, nu ca fapte din anunț:

  1. Inventar complet al abonamentelor Events și al scorurilor estimate.
  2. Clasificare pe priorități: peste 100, între 70 și 100, sub 70.
  3. Rescrierea interogărilor mari prin eliminarea câmpurilor nefolosite de handler.
  4. Separarea pe subiecte și pe trigger, acolo unde variabilele diferă.
  5. Testare în mediul de dezvoltare cu date reale de evenimente.
  6. Verificarea acoperirii datelor după rescriere, ca să nu pierzi câmpuri de care depinde logica internă.

Pasul 6 este cel care se sare cel mai des. Când tai câmpuri pentru a reduce complexitatea, riști să rupi handlerul. Ghidul de optimizare menționat de Shopify include verificări de acoperire exact pentru acest motiv. Dacă ai nevoie de peste 100 de puncte pentru un caz de utilizare legitim, anunțul indică forumul comunității ca loc în care să semnalezi situația.

FAQ

Această schimbare afectează și Classic Webhooks? Nu. Anunțul precizează explicit că reducerea limitei nu afectează Classic Webhooks. Vizează doar abonamentele Events și complexitatea interogărilor lor.

Interogările abonamentelor Events consumă din limita de rate a aplicației? Nu. Anunțul spune că interogările executate de abonamentele Events nu contează în limita de rate a API-ului aplicației tale. Limita de 100 de puncte se aplică per interogare de abonament, nu ca buget global de requesturi.

Ce fac dacă am un caz de utilizare care are nevoie legitim de peste 100 de puncte? Anunțul recomandă să semnalezi situația în forumul comunității Shopify. Înainte de asta, verifică dacă separarea pe subiecte și interogarea resursei schimbate nu rezolvă deja problema.

Arcul ALLSoft Agency

AI-ul te ajută să faci analiza: să scanezi interogările, să estimezi scoruri de complexitate, să generezi variante rescrise, să compari acoperirea datelor înainte și după. Este util și economisește ore bune de muncă repetitivă. Dar decizia despre ce câmpuri sunt cu adevărat necesare pentru handler, despre cum separi abonamentele și despre ce date nu ai voie să pierzi rămâne umană. Aici intervine media buyerul sau dezvoltatorul care cunoaște logica businessului, nu doar sintaxa interogării.

Pasul concret îl face ALLSoft Agency: audităm integrările, prioritizăm abonamentele problemă și lucrăm cu echipele tehnice ca schimbarea să nu se transforme în erori de sincronizare pentru tine. Fără hype, fără promisiuni de cifre pe care nu le putem susține cu date. Doar verificare, prioritizare și execuție.