Adobe Commerce Cloud Service: la release di ottobre apre il back office alle integrazioni

Su Adobe Commerce as a Cloud Service le regole del gioco sono cambiate: niente moduli PHP personalizzati, niente accesso diretto al database. Ciò che l’API non sa fare, la vostra integrazione non lo farà. Per questo la release del 7 ottobre 2026 merita una lettura attenta: su una dozzina di novità, quasi tutte ampliano la superficie di integrazione — carrelli, prezzi, B2B, email. Ecco cosa si apre, e il vincolo che lo accompagna.

Il carrello si apre ai sistemi terzi

Tre novità puntano allo stesso scenario: un sistema esterno — un OMS, un call center, uno strumento di vendita assistita — che deve creare o modificare carrelli senza disturbare il cliente.

• Il prezzo su misura. L’attributo di estensione custom_price consente di impostare un prezzo arbitrario su una riga di carrello tramite gli endpoint REST standard, riservato ai token admin e di integrazione. Preventivi negoziati, tariffe da call center, gesti commerciali: finora bisognava forzare le regole carrello per simulare tutto questo.
• I carrelli isolati. Un’opzione, disattivata per impostazione predefinita, separa i carrelli creati dall’admin o dalle integrazioni dal carrello storefront attivo del cliente. Basta con il carrello di preventivo che sovrascrive quello che il cliente stava riempiendo nello stesso momento.
• Lo sconto di spedizione libero. Un endpoint admin applica uno sconto di spedizione arbitrario a un carrello, per i casi che le regole standard non coprono — spedizione offerta dopo un incidente, condizione negoziata a contratto.

I prezzi di catalogo escono dalla schermata admin

Le regole di prezzo del catalogo ora si gestiscono in REST: creazione, modifica, cancellazione, ricerca e scoperta dei metadati. Un motore di pricing o un PIM può finalmente sincronizzare le regole invece di richiedere l’inserimento manuale. E le regole si pianificano ora all’ora esatta, non più solo al giorno: una vendita flash dalle 9 alle 13 non richiede più uno script fatto in casa.

Nel B2B, il webhook sa con chi parla

Il webhook delle tariffe di spedizione riceve ora il company_id del carrello e gli attributi personalizzati dell’azienda: un’integrazione App Builder può decidere l’idoneità di una tariffa negoziata senza richiamare Commerce. Arrivano insieme due serrature: un’opzione blocca la registrazione aziendale da parte di ospiti non autenticati (mutation createCompany), e reCAPTCHA può proteggere gli upload di file presigned. Sul fronte resi, l’API REST accetta attributi personalizzati sulle righe di reso — la sincronizzazione degli RMA con un ERP evita il passaggio dal GraphQL dello storefront.

Le email transazionali lasciano il monolite

Nuovi eventi permettono di inviare le email transazionali da una piattaforma terza — Salesforce Marketing Cloud, per esempio — tramite App Builder. Per i merchant che gestiscono già le campagne marketing in un ESP, è l’occasione per consolidare: stessi template, stessa deliverability, stesso reporting per la conferma d’ordine e la newsletter.

Il vincolo che accompagna l’apertura

Una riga della release non aggiunge nulla e può rompere l’esistente: la Bulk API impone ora un tetto di entità per richiesta, non configurabile, con errore oltre la soglia. Se i vostri import inviano lotti massicci, verificateli prima della prossima sincronizzazione completa — spezzare in blocchi diventa la norma, non un’ottimizzazione.

Da dove cominciare

• Riprendete il backlog di integrazione congelato « in attesa dell’API » e incrociatelo con questa release: regole di prezzo catalogo, prezzi custom e sconti di spedizione potrebbero già esserci.
• Verificate l’uso della Bulk API: dimensione dei lotti, gestione dell’errore sul superamento.
• Nel B2B, attivate la restrizione sulla registrazione aziendale e studiate il webhook arricchito se le vostre tariffe di spedizione dipendono dal contratto cliente.
• Se una revisione dell’emailing è in attesa, la via degli eventi verso un ESP terzo diventa l’opzione predefinita sul cloud service.

Su un SaaS, la roadmap del vendor è anche la vostra: ciò che l’API non offre oggi non è « da sviluppare », è « da attendere ». La release di ottobre mostra che l’attesa può essere breve — e che una lista di lacune non datata, anche qui, è una lista sbagliata.