Shopify a anunțat pe 16.09.2026 o serie de modificări la payload-urile Events, la sintaxa triggerilor și la headerele de livrare, conform changelog-ului oficial (Shopify Changelog). Abonamentele Webhook clasice nu sunt afectate. Modificarea contează pentru orice magazin care are integrări proprii, ERP conectat, sistem de stocuri sau fluxuri de automatizare care ascultă evenimente din Shopify.

Ce s-a schimbat, concret

Trei lucruri s-au modificat simultan, iar fiecare are impact diferit asupra codului.

Primul: fields_changed. Înainte era un array simplu de string-uri. Acum este un obiect cu trei array-uri separate: added, updated și removed. Practic, dezvoltatorul poate distinge dacă un element a fost adăugat, modificat sau șters fără să mai facă un query suplimentar ca să deducă ce s-a întâmplat. Exemplul dat de Shopify este clar: dacă adaugi o variantă la un produs, acțiunea rămâne update la nivel de produs, iar calea variantei apare în fields_changed.added.

Al doilea: triggerii de tip părinte cer acum un wildcard terminal explicit, .*. De exemplu, product.variants devine product.variants.*. Triggerii de tip frunză, cum ar fi product.variants.price, rămân neschimbați. Abonamentele existente continuă să funcționeze, dar trebuie actualizate la următorul deploy al fișierului shopify.app.toml. Shopify spune explicit că sintaxa nouă păstrează comportamentul de matching și volumul de evenimente pentru abonamente echivalente.

Al treilea: două headere redundante au fost eliminate din livrările de evenimente, shopify-event-id și shopify-resource-id. Recomandarea oficială este să actualizezi pachetele API Shopify la ultima versiune, care tratează deja schimbarea. Dacă propriul cod citește aceste headere sau le folosește pentru validare, dependența trebuie eliminată manual.

În plus, abonamentele de evenimente cu acțiunea update cer acum cel puțin un trigger prezent. Cele existente continuă să funcționeze.

De ce fields_changed structurat este o veste bună

Din perspectivă de inginerie, trecerea de la array plat la obiect cu trei chei este o îmbunătățire reală, nu doar birocrație de API. Motivul e simplu: înainte, ca să afli dacă o variantă a fost adăugată sau doar modificată, trebuia să faci un query comparativ sau să ții tu un istoric propriu. Acum informația vine în payload.

Pentru echipele de ecommerce care sincronizează stocuri, prețuri sau atribute de produs, asta reduce numărul de apeluri API. Mai puține apeluri înseamnă mai puțină presiune pe rate limits și mai puține puncte de eșec. Într-un magazin cu mii de SKU-uri și modificări frecvente, diferența se poate simți în stabilitatea sincronizării.

Totuși, atenție la o capcană de interpretare. Faptul că structura e mai bogată nu garantează că logica ta de business tratează corect fiecare caz. Cod care presupunea un array va arunca erori la parsare imediat ce primește un obiect. Acesta este tipul de schimbare care nu produce zgomot la lansare, dar crapă silențios într-un flux de noapte, exact când nu e nimeni la butoane.

Ce verifici în magazinele tale, pas cu pas

Aici trecem de la ce a anunțat Shopify la ce trebuie făcut efectiv. Pașii de mai jos sunt recomandarea noastră de lucru, nu instrucțiuni preluate din sursă.

  1. Inventariază toate integrările care consumă Events de la Shopify. Nu doar aplicația ta principală, ci și middleware-ul, conectorul ERP, scripturile de automatizare, tool-urile de analytics care ascultă webhook-uri.

  2. Caută în cod referințe la fields_changed. Dacă îl tratezi ca array, actualizează parsarea pentru structura cu added, updated, removed.

  3. Caută referințe la shopify-event-id și shopify-resource-id. Dacă validarea sau deduplicarea se bazează pe ele, mută logica pe identificatori din payload sau pe alte mecanisme de idempotență.

  4. Verifică fișierele shopify.app.toml pentru triggeri de tip părinte și adaugă .* terminal acolo unde lipsește.

  5. Rulează într-un mediu de test înainte de producție. Un abonament care nu mai livrează nimic din cauza unui trigger greșit nu dă eroare vizibilă, pur și simplu tace.

Un punct de transparență metodologică, pe care îl aplicăm constant: o verificare incompletă a codului nu dovedește absența unei dependențe. Faptul că nu găsești shopify-event-id într-o căutare rapidă nu înseamnă că nu este folosit undeva, de exemplu într-o bibliotecă terță sau într-un pachet compilat. Când probele sunt insuficiente, verificarea manuală rămâne necesară.

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

Dacă ai un magazin Shopify în România și te bazezi pe un dezvoltator extern sau pe o agenție pentru integrare, mesajul este simplu: întreabă acum, nu la următoarea problemă.

Patru întrebări pe care merită să le pui echipei tehnice, fără să intri în detalii de cod:

De ce contează pentru un om de marketing, nu doar pentru un developer: fluxurile care depind de Events sunt exact cele care alimentează stocul corect, prețurile afișate corect și, implicit, experiența de cumpărare. Un sincronizator care cade nu apare ca eroare în dashboard-ul de reclame, apare ca vânzări pierdute pe un produs care arăta stoc disponibil și nu mai era.

Asta se leagă de un tipar mai larg pe care l-am mai discutat: când se schimbă infrastructura de date din spatele unui magazin, impactul nu e niciodată izolat în zona tehnică. Despre cum modificări de API afectează direct operarea magazinelor am scris și în analiza pe market relationships în API-ul Shopify 2026-10, unde aceeași logică se aplică: integrarea se schimbă, comportamentul magazinului se schimbă.

Ipoteze versus fapte, cu scenarii ipotetice

Este important să separăm ce știm de la sursă de ce presupunem noi.

Fapte, din changelog: s-a schimbat structura fields_changed, s-a schimbat sintaxa triggerilor de tip părinte, s-au eliminat două headere, abonamentele Webhook clasice nu sunt afectate, abonamentele existente continuă să funcționeze până la următorul deploy.

Ipoteze plauzibile, marcate ca atare: un magazin cu o integrare veche, neîntreținută, care parsează fields_changed ca array, se va rupe la primul eveniment de tip update după ce pachetul API este actualizat. Nu avem date care să confirme că toate magazinele sunt expuse, dar structura schimbării face riscul previzibil pentru codul care presupune array.

Scenariu ipotetic: dacă un magazin modifică masiv prețuri într-o campanie și integrarea de sincronizare cade din cauza parsării, prețurile din feed ar putea rămâne neactualizate. Nu spunem că se întâmplă, spunem că acesta este tipul de lanț de efecte pe care merită să îl testezi înainte, nu după.

FAQ

Abonamentele mele Webhook actuale se rup? Nu automat. Shopify spune explicit că abonamentele Webhook clasice nu sunt afectate, iar cele de evenimente existente continuă să funcționeze. Problema apare la codul propriu care parsează fields_changed ca array sau citește headerele eliminate.

Trebuie să actualizez pachetele API Shopify? Changelog-ul recomandă actualizarea la ultima versiune, pentru că pachetele tratează deja schimbarea. Dacă ai cod propriu care citește headerele sau fields_changed, actualizarea pachetului nu te scutește de revizuirea codului tău.

Când trebuie făcută actualizarea triggerilor? La următorul deploy al fișierului shopify.app.toml. Abonamentele existente funcționează în continuare, dar triggerii de tip părinte trebuie trecuți pe sintaxa cu .* terminal când publici următoarea versiune.

Unghiul ALLSoft

AI-ul ajută la partea de analiză și planning: poate scana codul după referințe la câmpuri și headere, poate genera o listă de verificare, poate pregăti un draft de migrare. Ce nu face este să decidă pentru tine dacă o dependență este critică sau dacă un flux poate fi oprit fără impact real în business. Deciziile și execuția rămân umane, iar un media buyer sau un integrator care înțelege ambele capete, atât codul cât și operațiunea magazinului, este cel care validează și implementează.

Pasul concret îl face ALLSoft Agency împreună cu echipa ta: inventar de integrări, verificarea dependențelor, plan de migrare fără întreruperi. Fără hype, doar cu ce se poate verifica.