- Events, IFG-BLOG-AUTO, Integrazioni, Shopify API, Webhook
- Francesco Guiducci
Shopify Next Gen Events: cosa cambia rispetto ai webhook nel 2026
Con l’API Shopify 2026-10, Next Gen Events è diventato generalmente disponibile. È un cambio importante per chi sviluppa app e integrazioni, perché sposta il modello da “ricevo un webhook generico e poi interrogo Shopify” a “dichiaro quali cambiamenti mi interessano e quali dati voglio ricevere”.
Non significa che i webhook classici smettano di funzionare da un giorno all’altro. Significa però che, per nuovi flussi e integrazioni dove serve controllo più preciso, oggi esiste un’alternativa nativa progettata per ridurre consegne inutili e query successive.
Cosa sono i Next Gen Events di Shopify
Shopify li descrive come un sistema dichiarativo per ricevere eventi applicativi. La subscription vive nella configurazione dell’app e definisce quattro elementi fondamentali:
- la risorsa da osservare, per esempio Product;
- le azioni rilevanti, come create, update o delete;
- i campi che devono cambiare per generare una consegna;
- la query GraphQL che decide quali dati includere nel payload.
La differenza pratica è che l’app può ricevere un evento già più vicino al dato che le serve, invece di usare una notifica generica come semplice segnale per avviare altre chiamate Admin API.
La differenza rispetto ai webhook classici
Con un webhook classico, spesso l’evento comunica che una risorsa è cambiata. Se l’integrazione deve capire cosa è cambiato o recuperare dati collegati, normalmente serve una seconda query.
Con Events posso invece dichiarare nel file shopify.app.toml quali campi devono attivare la consegna e quale query deve comporre il payload. Questo riduce due problemi tipici delle integrazioni: notifiche che non interessano davvero il consumer e round trip aggiuntivi verso Shopify.
Triggers: ricevere solo i cambiamenti che servono
Per le subscription che includono l’azione update, Shopify richiede i triggers. Sono percorsi di campo che stabiliscono quali modifiche devono generare l’evento.
Un esempio semplice è un’app che deve reagire solo quando cambia il prezzo di una variante. Invece di ricevere ogni aggiornamento del prodotto, può dichiarare il percorso relativo al prezzo. Più trigger funzionano con logica OR.
È una differenza che considero importante soprattutto per integrazioni con molto traffico: filtrare prima la consegna è meglio che ricevere tutto e scartare dopo.
Query GraphQL nel payload
La subscription può includere una query GraphQL che determina i dati inviati con l’evento. In questo modo posso chiedere, per esempio, ID, stato e altri campi della risorsa coinvolta senza dover eseguire necessariamente una query separata dopo ogni notifica.
Questo non elimina ogni chiamata successiva in ogni architettura, ma consente di progettare payload molto più mirati rispetto al modello webhook tradizionale.
Query filter: un secondo livello di filtro
Dopo che Shopify ha costruito il risultato della query, può applicare anche un query_filter. È un filtro sui valori correnti restituiti dalla query, non sul delta dei campi.
Quindi i due meccanismi hanno ruoli diversi:
-
triggers: decide se una modifica specifica merita di attivare la subscription; -
query_filter: decide se il risultato corrente soddisfa le condizioni per inviare davvero la consegna.
Per esempio, posso reagire a una variazione di prezzo ma ricevere l’evento solo se il prodotto è attivo.
Cosa cambia nell’architettura di un’app Shopify
Il vantaggio non è semplicemente “meno webhook”. Il punto è poter avvicinare la selezione del dato alla sorgente.
Quando progetto un’integrazione, questo mi porta a verificare almeno quattro aspetti:
- quali eventi sono davvero necessari al consumer;
- quali campi devono scatenare una reazione;
- quali dati devono viaggiare nel payload;
- quali query successive restano comunque necessarie.
Se la subscription è troppo ampia, si perde una parte del beneficio. Se invece il payload è sovraccarico, si sposta semplicemente la complessità da una parte all’altra.
I webhook classici vanno eliminati subito?
No. Non consiglierei una sostituzione massiva senza prima mappare gli eventi esistenti e verificare la copertura dei topic necessari.
Shopify ha reso Next Gen Events generalmente disponibile con la versione 2026-10 su 18 topic. La migrazione va quindi trattata come una decisione architetturale, non come una pulizia automatica.
Il mio approccio sarebbe graduale: scelgo un flusso circoscritto, confronto il comportamento con il webhook corrente, verifico numero di consegne, completezza del payload, retry, idempotenza e gestione degli errori, poi estendo il modello solo se il risultato è migliore.
Perché questa novità conta anche per merchant e store complessi
Next Gen Events è una funzione per sviluppatori, ma l’effetto finale riguarda anche la qualità delle integrazioni usate dallo store. Meno eventi inutili e payload più mirati possono rendere più semplici flussi tra Shopify, ERP, sistemi logistici e applicazioni custom.
Questo però non significa automaticamente meno costi o più performance per ogni progetto. Il beneficio va verificato sul consumer reale e sul volume reale degli eventi.
Come valuterei una migrazione
Prima di cambiare una subscription esistente, partirei da una tabella molto concreta: webhook attuale, topic, consumer, dati letti dopo la consegna, volume medio, filtri applicati a valle e criticità note.
Poi costruirei una subscription Events equivalente e confronterei:
- copertura funzionale;
- numero di consegne;
- dimensione e utilità del payload;
- numero di query Admin API successive;
- comportamento nei retry e nei duplicati;
- facilità di debugging e manutenzione.
Per me il criterio resta lo stesso che uso nelle integrazioni Shopify in generale: non adottare una tecnologia perché è nuova, ma perché riduce davvero complessità o lavoro inutile senza peggiorare affidabilità e osservabilità.
Se stai lavorando su integrazioni più ampie, puoi leggere anche la mia guida su integrazione ERP Shopify, API e webhook e quella sulle verifiche da fare prima di aggiornare un’integrazione alla Shopify API 2026-10.
