Agosto 2026, le novità di Shopify sotto il cofano

Dal 5 agosto ogni negozio Shopify con tema Liquid espone al browser un insieme di strumenti che un agente AI può chiamare direttamente: cercare nel catalogo, gestire il carrello, portare il cliente al checkout, tutto dentro la scheda che il cliente ha davanti. Non c'è nulla da installare, nulla da configurare e nessun interruttore da alzare, è già acceso su tutti i negozi, e nel changelog occupa una decina di righe. Questa è forse la novità che fa più rumore tra tutte quelle presentate ad Agosto 2026 da Shopify. Vediamole tutte :-)

1.WebMCP, il negozio che parla agli agenti senza che nessuno l'abbia chiesto

WebMCP è una proposta di standard che permette a una pagina di registrare i propri strumenti presso il browser. Senza, un agente deve leggere il codice della pagina e simulare i clic sui bottoni e sui link, che è lento e sbaglia; con, chiama uno strumento dichiarato passando dati strutturati e ne riceve indietro altrettanti. Shopify sta lavorando alla specifica insieme a Google e Microsoft.

Gli strumenti esposti oggi sono dieci, divisi in quattro gruppi. Sul catalogo search_catalog, browse_store, get_product e show_variant, che leggono prodotti, collezioni e ricerche attraverso la Storefront API. Sul carrello get_cart, update_cart e cancel_cart. Su checkout e ordini proceed_to_checkout e manage_orders. Sui contenuti search_shop_policies_and_faqs.

Il dettaglio che conta più di tutti sta in una riga della documentazione: gli strumenti del carrello chiamano le standard storefront action, cioè le stesse funzioni su Shopify.actions che usano le app, quindi se il tema è configurato per aprire il drawer del carrello a ogni aggiornamento, quel drawer si apre anche quando a premere è una macchina. Il comportamento del tema, che fino a ieri era una questione di esperienza umana, è diventato la superficie su cui agisce un agente, e tutto avviene sulla sessione viva del cliente, nella scheda che sta guardando.

La riserva è che WebMCP resta uno standard emergente e il supporto lato agente oggi si limita ai browser basati su Chromium: il commercio agentico, qui, ha la sua infrastruttura pronta prima del suo pubblico. Sul lato headless gli strumenti sono attivi sulla developer preview di Hydrogen, non sulla versione stabile.

2. Gli script tag hanno finalmente una data

Il 24 agosto Shopify ha messo per iscritto la fine degli script tag sullo storefront, con due date e nessuna via di fuga.

Dal primo ottobre 2026 le mutation scriptTagCreate e scriptTagUpdate restituiscono un errore utente, e la risorsa ScriptTag della REST Admin API rifiuta POST e PUT. La deprecazione vale su tutte le versioni dell'API, comprese quelle vecchie, quindi restare inchiodati a una versione non sposta la data di un giorno: è la riga che merita di essere letta due volte da chi ha l'abitudine di pinnare per rimandare.

Dal primo marzo 2027 Shopify smette proprio di iniettare gli script nello storefront, che era rimasto l'ultimo posto in cui gli script tag ancora giravano dopo che avevano già smesso di funzionare sulla pagina di stato dell'ordine. La query scriptTags e la mutation scriptTagDelete continuano a funzionare, così l'inventario di quello che c'è e la pulizia restano possibili.

Riguarda le app che creano script tag con display_scope impostato a online_store. Le due strade di migrazione non sono equivalenti, e la differenza sta in chi deve muoversi: un app embed block, che si spedisce dentro una theme app extension, va attivato dall'utente dell'app nell'editor del tema, quindi uno sviluppatore che migra senza avvisare nessuno lascia il codice spento e il merchant senza una spiegazione; un web pixel, ammesso solo quando lo script raccoglie unicamente dati di analytics e di conversione, non richiede nulla a chi usa l'app.

3. L'altra scadenza del primo ottobre, quella che colpisce i negozi in costruzione

Il 27 agosto è arrivata una seconda scadenza sullo stesso giorno. Dal primo ottobre 2026 i comandi theme della Shopify CLI sulle vetrine protette da password richiedono la versione 3.84.0 o successiva, perché le 3.83.x e precedenti usano un'autenticazione dello storefront ormai legacy che smette di essere supportata.

Colpisce shopify theme dev, shopify theme console e shopify app dev quando l'app ha theme app extension. Detto in termini di progetto: un negozio in costruzione è protetto da password per definizione, quindi la scadenza cade esattamente sui lavori in corso e non su quelli già online. Si aggiorna con npm install -g @shopify/cli@latest e si verifica con shopify version; la 3.84.0 è il minimo, la 4.7.0 è quella che Shopify consiglia. L'altra via dichiarata, togliere la protezione con password dalla vetrina, su un progetto non ancora annunciato non è una via.

4. L'inventario che cambia significato senza rompere niente

Il 5 agosto Shopify ha annunciato che le quantità trattenute da bozze d'ordine, trasferimenti e spedizioni si spostano dallo stato reserved allo stato committed, per allinearle a come è già rappresentato l'inventario degli ordini: committed diventa tutto ciò che è impegnato ma non ancora evaso.

È una migrazione una tantum, tocca solo le bozze attive e i trasferimenti e le spedizioni ancora aperti che stanno trattenendo inventario nel momento in cui gira, e lascia stare quelli completati, annullati o già rilasciati. Le quantità available e on_hand non cambiano, il totale non cambia, nessun campo viene rimosso o rinominato ed entrambi i nomi restano validi e interrogabili: si sposta merce fra due secchi che erano già entrambi indisponibili, e quello che il cliente può comprare non si muove di un pezzo.

Ed è questo il motivo per cui va guardata con attenzione invece che archiviata come una nota tecnica. Nessuna query si rompe, nessun errore compare da nessuna parte, e i numeri cambiano da soli: un'app che legge InventoryLevel.quantities(names: ["reserved"]) vedrà reserved scendere e committed salire senza che nessuno abbia toccato una riga di codice. Chi usava reserved per riconoscere le trattenute da bozza o da trasferimento deve passare a leggere committed. Sul lato merchant, i report di rettifica dell'inventario mostrano i valori migrare più una voce di correzione una tantum quando la migrazione gira, mentre lo storico precedente resta com'era.

5. Oxygen scende sui negozi che non pagano

Due voci a tre settimane di distanza, il 3 e il 25 agosto, portano Oxygen prima sui development store e poi sui negozi in prova. Prima serviva un piano a pagamento.

Seguendo il rimando alla documentazione, il quadro completo è questo: Oxygen è incluso senza costi aggiuntivi su Starter, Basic, Grow, Advanced, Plus e Pause and build, mentre non è disponibile sui piani Agentic. Su development store, Plus Partner Sandbox e piani di prova si può costruire e provare una vetrina Hydrogen prima che il negozio vada online.

Il numero che separa davvero i piani, però, non è il prezzo, sono gli ambienti pubblici: venticinque su Shopify Plus, uno su tutti gli altri piani a pagamento e uno anche su retail, nonprofit e piani custom, zero sui development store e sui piani di prova. Zero significa che gli URL di deploy funzionano ma chiedono sempre il login al negozio, il che come ambiente di lavoro va benissimo e come link da mandare al cliente per una revisione no.

6. Il refresh dei token che perdona un errore di scrittura

Il 28 agosto è cambiato il comportamento del refresh degli offline access token con scadenza, e la differenza si misura in ordini di grandezza. Prima, dopo aver usato un refresh token, l'app poteva riprovare con lo stesso per un'ora al massimo; passata quella finestra, se la risposta si era persa o non era stata salvata, il token precedente non valeva più. Adesso l'app può riprovare con il refresh token che ha in archivio finché non comincia a usare il sostituto, con un periodo di recupero di trenta giorni dal primo uso del token originale e senza estenderne la vita normale di novanta giorni.

Il caso che risolve è banale e capita: un'interruzione di rete, un worker che muore, una scrittura su database che fallisce dopo che Shopify ha già processato il refresh e prima che l'app abbia salvato la coppia di token. Da lì, prima, si usciva solo facendo riaprire l'app al merchant. Non serve una versione nuova dell'API, non serve configurare niente e non c'è nulla a cui aderire; restano da rispettare le regole di sempre, serializzare i refresh per negozio, salvare ogni coppia restituita in modo atomico e usare sempre il token più recente.

7. PHP e Python entrano dalla porta principale

Il 26 agosto sono arrivati alla versione 1.0 due pacchetti ufficiali e open source per costruire app Shopify: shopify/shopify-app-php su Packagist e shopifyapp su PyPI. Non sono framework, sono primitive indipendenti dallo stack: verifica delle richieste per webhook, App Home, App Bridge, app proxy e per le estensioni Checkout, POS, Admin, Customer Account e Flow; token exchange comprese le client credentials e il refresh dei token già scambiati; un client GraphQL Admin con la gestione automatica dei tentativi. Funzionano con Laravel, Symfony, Django, FastAPI o con PHP e Python nudi.

La riga da non saltare riguarda le librerie precedenti: shopify-api-php è segnata come abbandonata su Packagist e shopify_python_api come inattiva su PyPI. Continuano a funzionare, ma non riceveranno più né funzioni nuove né correzioni di sicurezza, e questo è il tipo di frase che sposta una priorità di manutenzione da "quando capita" a "questo trimestre".

Non c'è un template di app per PHP e Python, il progetto si compone da soli, e per le app nuove Shopify continua a consigliare React Router. Per un'azienda il cui gestionale e i cui integratori vivono in PHP o in Python, però, la conseguenza pratica è che parlare con Shopify non richiede più di tenere in piedi un servizio Node messo in mezzo solo per quello.

8/15. Il resto del mese

8. Shop Campaigns su ShopifyQL (10 agosto): lo schema shop_campaign_insights si interroga con il campo shopifyqlQuery e lo scope read_reports, e restituisce spesa, vendite, ordini, ROAS, valore medio dell'ordine e costo medio di acquisizione, per campagna, per segmento di clientela e su intervalli che vanno dall'ora all'anno nel fuso del negozio. Nella stessa voce arrivano gli Analytics Web Components e l'Analytics Annotations API, per annotare i grafici del merchant.

9. Hydrogen, developer preview del 18 agosto: attribuzione della sessione del carrello, così chi ha fatto login arriva al checkout con i propri dati invece che come ospite; attributi sul carrello, anche riga per riga; eventi di page view a ogni navigazione e non più solo al primo caricamento; il bottone Shop Pay che si disegna subito senza aspettare shop-js; HTTPS locale per sviluppare i flussi di Customer Account senza tunnel né certificati fatti a mano; logging collegabile alla propria osservabilità.

10. Events, quattro topic nuovi (26 agosto): Metaobject, MetafieldDefinition, MetaobjectDefinition e InventoryTransfer, con la possibilità di far scattare il trigger sul singolo campo invece che sull'aggiornamento intero. Resta in developer preview sulla versione unstable.

11. Attributi del carrello negli eventi standard (6 agosto): updateCart ora aggiorna anche gli attributi e un nuovo evento shopify:cart:attributes-update scatta a ogni modifica, che arrivi dall'app, dal tema o da un'altra app.

12. App intent a pagina piena (19 agosto): gli intent dichiarati su admin.app.intent.link e invocati da Sidekick aprono l'app come pagina intera invece che in overlay; il modale resta solo quando il merchant ha modifiche non salvate.

13. orderCreate con più tracking (3 agosto): il campo trackingNumbers accetta un array quando si importano ordini che partono in più colli, dalla versione API 2026-10; se si passano sia il singolare sia il plurale, vince il singolare e le integrazioni esistenti non cambiano comportamento.

14. Built for Shopify, requisiti più larghi per i fulfillment (1 agosto): ritoccati i criteri 5.8.2, 5.8.6 e 5.8.7 su tasso di completamento e finestre di risposta, senza che serva fare nulla; le app che prima restavano appena sotto la soglia potrebbero ora qualificarsi.

15. I commit del tema dicono chi ha modificato (26 agosto): il commit che Shopify spinge sul branch collegato riporta in chiaro nel corpo il nome dell'ultimo che ha salvato dall'editor, mentre l'autore resta il bot, quindi git blame non cambia. Le modifiche salvate a una decina di secondi l'una dall'altra finiscono in un commit solo, intestato a chi ha salvato per ultimo.

Le due date da segnare in calendario sono il primo ottobre 2026, che vale sia per le mutation degli script tag sia per la Shopify CLI sulle vetrine protette da password, e il primo marzo 2027, quando gli script tag smettono di girare.