Due software comunicano quando un dato passa dall’uno all’altro senza che nessuno lo ricopi a mano. Per esempio, l’ordine del sito entra nel gestionale e il contatto lasciato nel modulo finisce nel CRM. Le scelte che contano spettano a chi conosce il processo: quali dati devono passare, in che direzione, ogni quanto e quale dei due sistemi ha l’ultima parola. Qui trovate le strade possibili e le domande da farsi prima di scegliere.
Cosa vuol dire, in pratica, far comunicare due software?
Vuol dire stabilire un canale automatico tra due sistemi e le regole per usarlo. Molte aziende italiane ne hanno già uno, spesso senza chiamarlo così. Dal 1° gennaio 2019 le fatture tra soggetti residenti o stabiliti in Italia devono essere, salvo alcune eccezioni, file XML trasmessi al Sistema di Interscambio (SdI) dell’Agenzia delle Entrate. Dal 1° gennaio 2024 l’obbligo vale anche per tutti i forfettari. Il collegamento tra il gestionale che prepara la fattura e il SdI, diretto o tramite un intermediario, è un’integrazione a tutti gli effetti. Il formato lo stabilisce l’Agenzia, il file viaggia su un canale previsto e per ogni invio torna una ricevuta con l’esito: consegna, mancata consegna o scarto. La guida dell’Agenzia sulla fattura elettronica ricorda che ricevere le fatture in XML permette di registrarle più in fretta e con meno errori rispetto all’inserimento manuale.
Molte aziende, poi, non hanno ancora i software da collegare. Secondo l’Istat, nel 2025 usava un gestionale ERP il 48,8% delle PMI italiane (tra 10 e 249 addetti), contro l’85,9% delle grandi imprese. Un CRM lo usava il 21,1% delle PMI, contro il 56,5% delle grandi. Sul CRM l’Italia resta sotto la media europea: lo usa il 21,7% delle imprese con almeno 10 addetti (Istat), contro il 28,5% della media UE (Eurostat). Sui gestionali ERP, invece, è sopra: 49,5% contro 46,5%. E dove i software ci sono, non è detto che si parlino. Nel Connectivity Benchmark Report 2026 di Salesforce (MuleSoft), un sondaggio tra 1.050 responsabili IT di aziende con almeno mille dipendenti in nove paesi, Italia esclusa, solo il 27% delle applicazioni in uso risulta collegato alle altre.
Cosa sono le API e i webhook?
Un’API è lo sportello che un software apre verso gli altri programmi: un elenco di richieste ammesse, come “dammi gli ordini di oggi” o “crea questo cliente”, con regole precise su formato e permessi. Un webhook funziona al contrario, come un campanello. Invece di chiedere ogni cinque minuti se c’è qualcosa di nuovo, il sistema di partenza avvisa quello di arrivo quando succede un evento, per esempio un nuovo ordine. Spesso si usano insieme: il webhook avvisa, l’API recupera i dettagli.
Chi decide dovrebbe conoscere due dettagli. Il primo è che le API hanno dei limiti, spesso legati al piano che pagate. Su Shopify ogni app collegata a un negozio con un piano inferiore ad Advanced dispone di 100 punti al secondo, con Shopify Plus di 1.000. I punti misurano il peso delle richieste: una modifica, per esempio, ne costa 10. HubSpot concede alle integrazioni private, cioè create per un solo account, 250.000 chiamate al giorno sui piani Free e Starter, 625.000 su Professional e un milione su Enterprise; il tetto giornaliero vale per l’intero account ed è condiviso tra tutte le integrazioni. Il piano gratuito di Airtable si ferma a 1.000 chiamate al mese per area di lavoro (workspace). Prima di progettare un’integrazione conviene verificare che il vostro piano regga i volumi previsti.
Il secondo è che i webhook non sono infallibili. Stripe e Shopify scrivono nella loro documentazione che non garantiscono l’ordine di arrivo degli eventi. Stripe consiglia di registrare gli identificativi degli eventi già elaborati per scartare i doppioni. Shopify avverte che la consegna stessa non è sempre garantita e consiglia di rileggere periodicamente i dati tramite API. L’integrazione deve quindi reggere notifiche doppie, fuori sequenza o perse. Altrimenti crea due ordini uguali o aggiorna una giacenza con un dato vecchio.
Quali sono le strade per collegare due software?
Le strade sono cinque. Le prime tre sfruttano le API dei software, direttamente o tramite strumenti già pronti. Le ultime due servono soprattutto quando le API mancano. Quale scegliere dipende dai vostri dati e dai vostri volumi.
| Strada | Come funziona | Quando va bene | Limiti da conoscere |
|---|---|---|---|
| Connettore pronto | Uno dei due software, o un’app del suo marketplace, offre già il collegamento con l’altro: lo si attiva dalle impostazioni | Coppie di software molto diffusi e flussi standard | Fa solo quello che ha previsto chi l’ha sviluppato. Se è di terze parti, ha un canone e un’assistenza a parte |
| Piattaforma di integrazione (Zapier, Make, n8n, Power Automate) | Si costruisce il flusso collegando blocchi già pronti, con poco o nessun codice | Pochi flussi, volumi contenuti, logica semplice, prototipi | Il costo cresce con l’uso, la logica complessa diventa difficile da mantenere, i dati passano dai server del fornitore (salvo n8n installato sui vostri) |
| Integrazione su misura tramite API | Uno sviluppatore scrive il codice che legge e scrive i dati attraverso le API dei due sistemi, spesso con un piccolo servizio intermedio (middleware) | Flussi in entrambe le direzioni, regole specifiche della vostra azienda, volumi alti, più di due sistemi | Costa di più all’inizio e va aggiornata quando cambiano le API |
| Scambio di file | Un sistema esporta un file (CSV o XML) a orari fissi e l’altro lo importa, di solito tramite una cartella condivisa o un server SFTP, un servizio per lo scambio protetto di file | Software senza API, dati che non devono arrivare in tempo reale | Niente tempo reale, errori scoperti tardi, formati fragili |
| Vie di ripiego | Accesso diretto al database, oppure un robot software (RPA) che usa l’interfaccia come farebbe una persona | Sistemi vecchi e chiusi, quando le altre strade non esistono | Può rompersi a ogni aggiornamento. Scrivere direttamente nel database salta i controlli del gestionale e può far perdere l’assistenza del fornitore; leggere è meno rischioso |
Sulle piattaforme di integrazione vale la pena leggere bene le condizioni, perché ognuna misura l’uso a modo suo. Zapier conta i task, cioè le azioni completate: l’evento che avvia il flusso non si paga. Make usa i crediti, e di norma ogni passaggio eseguito ne consuma uno. n8n conta le esecuzioni, cioè ogni volta che il flusso gira dall’inizio alla fine, qualunque sia il numero di passaggi; la versione Community installata sui propri server è gratuita. Power Automate si paga con licenze per utente o per singolo flusso, e alcune licenze Microsoft 365 ne includono già una versione limitata. Un flusso con quattro azioni che gira mille volte al mese vale quindi circa 4.000 task su Zapier, almeno 4.000 crediti su Make e 1.000 esecuzioni su n8n.
Conta anche dove passano i dati. Zapier li ospita su server negli Stati Uniti e non offre l’opzione di tenerli solo in Europa. Il trasferimento è oggi ammesso perché Zapier aderisce al Data Privacy Framework UE-USA, riconosciuto dalla Commissione europea nel 2023. Make fa scegliere un data center europeo o americano quando si crea l’organizzazione, cioè l’account aziendale, e la scelta poi non si può cambiare. n8n si può installare sui propri server: i dati restano dove decidete voi, ma aggiornamenti, sicurezza e backup diventano un vostro compito. Se passano dati personali, il GDPR (articolo 28) richiede un contratto scritto, anche in formato elettronico, con chi li tratta per vostro conto, compreso chi ospita il server o gestisce l’integrazione. Di solito è l’accordo sul trattamento dei dati (DPA) che il fornitore mette a disposizione.
L’integrazione su misura è la strada più flessibile e la più impegnativa. Per costi e tempi di un caso tipico rimandiamo alla guida sull’integrazione tra CRM ed ERP, dove trovate le fasce di investimento indicative.
Quali domande fare prima di scegliere?
Prima di scegliere servono le risposte a queste domande. Sono loro a indicare la strada:
- Quali dati devono passare, esattamente? Non “i clienti”, ma quali campi, con quali codici e in quale formato.
- In che direzione? Un flusso in una sola direzione è molto più semplice di uno bidirezionale, dove due sistemi possono modificare lo stesso dato e servono regole per i conflitti.
- Con che frequenza? Le giacenze di un ecommerce vanno aggiornate quasi in tempo reale; un riepilogo per la contabilità può passare una volta al giorno.
- Chi comanda su ciascun dato? Per ogni informazione deve esserci un solo sistema di riferimento: i prezzi nel gestionale, lo stato della trattativa nel CRM. Gli altri leggono.
- Dove si trova il gestionale? Se è installato su un server in azienda, i servizi cloud come Shopify, Zapier o Make non lo raggiungono direttamente. Serve un piccolo componente installato in sede o un servizio intermedio che faccia da ponte. Aprire il database verso internet non è una soluzione.
- Cosa succede quando qualcosa va storto? Chi viene avvisato, dove si vede l’errore, come si recupera il dato perso.
- Quanti dati passano, e quanto cresceranno? I volumi decidono se bastano i limiti delle API e quanto costerà la piattaforma.
- Chi la manterrà? Un’integrazione può smettere di funzionare quando uno dei due sistemi cambia versione, e qualcuno deve accorgersene.
- Dove passano i dati? Per i dati personali contano il paese in cui vengono trattati e il contratto con il fornitore.
Quale strada scegliere nei casi più comuni?
Dipende da quali dati passano e con che frequenza. Nei tre casi più frequenti la scelta di solito è questa:
| Caso | Dati che passano | Direzione e frequenza | Strada di solito adatta |
|---|---|---|---|
| Ecommerce e gestionale | Ordini dal sito al gestionale; giacenze e prezzi dal gestionale al sito | Due flussi opposti su dati diversi; giacenze quasi in tempo reale | Connettore, se esiste per quella coppia di software; altrimenti integrazione su misura |
| Sito e CRM | Contatti dal modulo del sito al CRM | Una direzione; subito, tramite webhook | Connettore o piattaforma di integrazione |
| CRM e gestionale | Anagrafiche, offerte, ordini, stato dei pagamenti | In entrambe le direzioni; più volte al giorno | Integrazione su misura quando ci sono regole specifiche della vostra azienda |
Con ecommerce e gestionale il punto delicato sono le giacenze: un dato vecchio di qualche ora può significare vendere un prodotto che non c’è. Tra sito e CRM bastano pochi accorgimenti: un controllo sui contatti doppi e il passaggio del consenso privacy raccolto dal modulo, con data e testo accettato, perché il GDPR chiede di poterlo dimostrare. CRM e gestionale sono il caso più impegnativo, perché due sistemi modificano dati collegati: le regole su chi comanda vanno fissate prima dello sviluppo.
Quali sono gli errori più comuni?
Sono sei, e quasi tutti nascono da decisioni rimandate.
- Non decidere chi comanda sul dato. Se entrambi i sistemi possono modificare lo stesso campo senza regole, prima o poi si sovrascrivono a vicenda.
- Codici diversi per la stessa cosa. Lo stesso prodotto ha un codice nel sito e un altro nel gestionale, lo stesso cliente due anagrafiche. Senza una tabella di corrispondenza, l’integrazione sposta la confusione più velocemente.
- Errori silenziosi. Un flusso si interrompe e nessuno se ne accorge per giorni. Ogni integrazione ha bisogno di un avviso quando fallisce e di un registro delle operazioni.
- Flussi legati all’account personale di un dipendente. Succede spesso con le piattaforme di integrazione: il flusso vive nell’account di chi l’ha creato, e quando quella persona cambia lavoro si ferma tutto. Meglio collegare i flussi a un account aziendale e a un utente tecnico dedicato, con i soli permessi che servono.
- Collegamenti a coppie che si moltiplicano. Cinque sistemi collegati ognuno con ognuno fanno fino a dieci integrazioni diverse da mantenere. Con un punto centrale, cioè un middleware o una piattaforma di integrazione, ogni sistema ha un solo collegamento: con cinque sistemi, cinque.
- Automatizzare un processo mai descritto. Se il passaggio manuale nasconde decisioni o eccezioni che nessuno ha mai scritto, l’integrazione le perde. Il processo va descritto prima di collegare i sistemi.
Quando conviene integrare, e quando no?
Conviene quando i dati passano spesso e un errore di trascrizione ha un costo concreto, come un ordine sbagliato o una fattura da rifare. Conviene anche quando il ritardo si vede dal cliente. Può non convenire, almeno per ora, se l’operazione capita poche volte al mese o se il processo cambia di continuo. Se uno dei due software sta per essere sostituito, aspettate e collegate quello nuovo.
Se i dati di partenza sono fogli di calcolo che girano via email, forse prima di integrare serve un software vero: ne abbiamo parlato nei segnali che dicono quando Excel non basta più. Se invece arrivano in forma non strutturata, come email, PDF o messaggi, prima vanno estratti e trasformati in dati. Oggi lo si fa spesso con l’AI, anche con gli AI agent, purché ci siano i controlli descritti parlando di cosa succede quando un agente bara.
In sintesi
Le strade sono cinque: connettore pronto, piattaforma di integrazione, integrazione su misura tramite API, scambio di file e, come ripiego, accesso al database o robot software. La scelta dipende da quali dati passano, in che direzione, con che frequenza e da quale sistema ha l’ultima parola su ciascun dato. Prima di decidere verificate i limiti delle API legati al vostro piano, dove vengono trattati i dati, dove si trova il gestionale e chi manterrà l’integrazione nel tempo. Poi partite dalla strada più semplice che regge i volumi e le eccezioni reali.
Fonti: Istat, Imprese e ICT, anno 2025; Eurostat, E-business integration; Salesforce, Connectivity Benchmark Report 2026; Agenzia delle Entrate, La fattura elettronica e i servizi gratuiti e novità 2024; Zapier, prezzi e privacy dei dati; Make, crediti e organizzazioni e data center; n8n, prezzi e self-hosting; Microsoft, licenze di Power Automate; GDPR, articoli 7 e 28; Shopify, limiti delle API e webhook; HubSpot, limiti di utilizzo delle API; Airtable, limiti delle chiamate API; Stripe, webhook. Dati verificati il 25 settembre 2026.