Odoo 19 e i Webhook

Prima di tutto: cosa fa un webhook in Odoo

Abbiamo già esplorato come i Webhook in Odoo rappresentino uno strumento chiave per far comunicare l'ERP con il mondo esterno. Per entrare più a fondo nell'argomento, però, è necessario partire da una distinzione fondamentale, la direzione del flusso dati,  che viene spesso fraintesa anche in contesti tecnici.

I webhook nativi di Odoo, configurabili tramite Studio, sono principalmente un meccanismo in entrata (inbound): permettono di automatizzare un'azione nel database Odoo quando si verifica un evento in un sistema esterno. In pratica, il sistema esterno invia una richiesta POST all'URL generato da Odoo, e Odoo esegue un'azione predefinita (aggiorna un record, crea un lead, sincronizza un inventario…).

Esiste anche la direzione opposta: tramite le Automated Actions è possibile configurare Odoo affinché invii una notifica POST a un endpoint esterno quando avviene un evento interno (ad esempio, la conferma di un ordine di vendita). Questa funzione,spesso chiamata outbound notification, è reale e utile, ma si tratta di una funzionalità delle regole di automazione, non del meccanismo webhook in senso proprio.

Tenere separate queste due direzioni è essenziale per progettare correttamente un'integrazione.

Il livello di complessità tecnica reale

La documentazione ufficiale di Odoo è esplicita su un punto che vale la pena citare direttamente: è fortemente raccomandato coinvolgere uno sviluppatore, un solution architect o una figura tecnica equivalente sia nella fase decisionale che durante l'implementazione, perché una configurazione errata può compromettere il database.

Il motivo è semplice: la complessità varia molto in base al caso d'uso.

• Integrazione tra due database Odoo: la configurazione è gestibile senza codice, direttamente dall'interfaccia Studio. È il caso più semplice e anche il più documentato.
• Integrazione con sistemi non-Odoo: la gestione del target record — ovvero come Odoo identifica il record su cui agire a partire dal payload ricevuto — richiede quasi sempre intervento tecnico. Per creare record da zero, ad esempio, è necessario adattare la logica di ricerca (model.browse o model.search), operazione che presuppone familiarità con il framework.
• Azioni personalizzate: quando l'azione da eseguire va oltre i casi standard (modifica di campo, invio email), è spesso necessario codice Python.

In Unitiva, nelle nostre implementazioni su ambienti di produzione, raccomandiamo sempre di testare il webhook su un database duplicato prima di procedere, seguendo le indicazioni della documentazione ufficiale.

Scenari applicativi concreti

Chiarito il quadro tecnico, i casi d'uso rimangono molto validi.

Ricezione di dati da sistemi di cassa o e-commerce (inbound): un sistema POS esterno o una piattaforma e-commerce può inviare a Odoo la conferma di una vendita nel momento in cui avviene. Odoo riceve il payload, individua o crea il record corrispondente e aggiorna l'inventario o la contabilità. L'integrazione avviene senza modificare il codice sorgente dei moduli coinvolti, il che ne preserva l'aggiornabilità nel tempo.

Notifiche verso sistemi di collaborazione (outbound): tramite le Automated Actions, è possibile configurare Odoo affinché invii un messaggio a Slack o Microsoft Teams al verificarsi di determinati eventi — ad esempio il superamento di una soglia su un'offerta commerciale. Anche qui, nessuna modifica al core.

Sincronizzazione con WMS legacy: se il software di magazzino dispone di un endpoint in grado di ricevere POST, è possibile inviare automaticamente i dati di un ordine validato. È il caso in cui la funzione outbound delle Automated Actions si rivela particolarmente utile.

Il vero vantaggio architetturale

Al di là dei singoli scenari, il valore strutturale di questo approccio è la separazione tra logica di integrazione e codice sorgente del modulo. Le regole di automazione — sia inbound che outbound — vivono a un livello superiore rispetto al codice Python dei modelli. Questo significa che, al momento di un aggiornamento di versione, il rischio di conflitti tecnici è significativamente ridotto rispetto a soluzioni basate su moduli custom che intervengono direttamente sui modelli.

Il sistema di logging integrato — attivabile per entrambi i tipi di configurazione — offre visibilità su ogni chiamata effettuata o ricevuta, inclusi i codici di risposta e gli eventuali errori. Per chi gestisce integrazioni in produzione, è uno strumento di monitoraggio concreto.

Una nota sull'autenticazione

La gestione dell'autenticazione nelle chiamate outbound (API Key, token Bearer negli header) è un'area che merita attenzione. Alcune funzionalità in questo ambito potrebbero essere state rafforzate in Odoo 19, ma si tratta di un aspetto da verificare puntualmente sulla documentazione ufficiale aggiornata o direttamente sull'installazione, prima di includerlo nei requisiti di un progetto.

Conclusione

I webhook e le notifiche outbound di Odoo sono strumenti solidi per costruire integrazioni che non vincolano il core del sistema. Non sono però strumenti universalmente no-code, e richiedono una valutazione tecnica attenta prima dell'implementazione.

In Unitiva, il nostro approccio è quello di affrontare ogni integrazione partendo dall'analisi del flusso dati corretto, distinguendo chiaramente cosa deve entrare in Odoo e cosa deve uscire,  per poi dimensionare il livello di complessità tecnica necessario. In molti casi il risultato è un'architettura pulita e manutenibile; in alcuni casi richiede codice. La differenza sta nel saperlo prima di iniziare.