Webhook cos'è: come funziona, esempi in azienda e cosa fare se si perde
Il webhook è il messaggio con cui un programma avvisa un altro programma che è successo qualcosa. Semplice finché funziona: il problema è cosa fai quando non arriva.
Webhook cos'è: un campanello al posto del controllo continuo
Un webhook è un messaggio che un programma invia da solo a un altro indirizzo web nel momento in cui succede qualcosa: un ordine pagato, un modulo compilato, un appuntamento fissato. Non devi chiedere se ci sono novità: arrivano loro. Il programma che riceve, a quel punto, fa partire il passo successivo.
Pensa al corriere. Puoi andare al suo magazzino ogni mezz'ora a chiedere se il pacco è arrivato, oppure lasciare il numero di telefono e aspettare la chiamata. Il primo modo si chiama polling, e funziona, ma consuma tempo e quasi sempre la risposta è «ancora no». Il secondo è un webhook. Il telefono squilla solo quando c'è qualcosa da dire.
Dentro il messaggio c'è un piccolo pacchetto di informazioni: che cosa è successo, a chi, quando, con quali cifre. Chi lo riceve lo legge e decide cosa fare. Tutto qui. Il resto è dettaglio tecnico, che serve a chi lo costruisce, non a chi deve capirlo per decidere.
Webhook e API: la differenza che ti serve davvero
Le due parole vengono spesso confuse perché lavorano insieme. L'API è la porta di un programma: se la conosci, puoi bussare e chiedere o inserire qualcosa quando vuoi tu. Il webhook è il contrario: è il programma che bussa a te quando ha una novità. Per questo qualcuno li chiama «API inverse», definizione corretta anche se poco intuitiva.
| API | Webhook | |
|---|---|---|
| Chi parte | Tu, quando ti serve | Il programma, quando succede un fatto |
| Quando arriva l'informazione | Quando la chiedi | Subito, o quasi |
| Se non succede nulla | Chiedi a vuoto | Silenzio |
| Rischio tipico | Dimenticarsi di chiedere | Non accorgersi che non è arrivato nulla |
L'ultima riga è quella che conta. Con l'API, se qualcosa va storto, di solito la richiesta fallisce e lo vedi. Con il webhook il guasto è muto, perché l'assenza di un messaggio non fa suonare nessun allarme. Ci torniamo fra poco.
Webhook cos'è in pratica: esempi in azienda
Molti strumenti che usi ne hanno uno, anche se nelle impostazioni si chiama «notifiche», «integrazioni» o «eventi». Alcuni casi concreti:
- Un modulo sul sito. Qualcuno chiede un preventivo, il sito manda il messaggio, il CRM crea la scheda e assegna la richiesta al commerciale che segue quel settore. Ne parliamo nel dettaglio in automazione della gestione dei lead, dal modulo al commerciale giusto.
- Un pagamento. Il sistema di incasso avvisa che la fattura è saldata, e lo scadenzario si aggiorna senza che nessuno spunti righe.
- Un ordine nel negozio online. L'ordine arriva, il gestionale scala la giacenza, il corriere riceve la richiesta di ritiro.
- Una firma. Il cliente firma la proposta e si apre in automatico la pratica di avvio lavori.
- Una risposta a una campagna. Qualcuno risponde a una cold email e il messaggio finisce nel punto dove lo vede chi deve gestirlo, invece di restare in una casella.
Il denominatore comune: qualcuno, oggi, fa un copia e incolla o un controllo ricorrente. Se la frase «ogni volta che arriva X, io faccio Y» descrive una tua giornata, in quel punto c'è quasi certamente un webhook che aspetta di essere usato. Se il lavoro ripetuto è tanto e sparso fra più programmi, vale la pena guardare come si costruiscono automazioni su misura prima di collegare tutto a mano.
Cosa succede quando un webhook si perde
Succede, e in genere nel momento peggiore. Un venerdì sera un cliente paga un ordine. Il sistema di pagamento manda il messaggio, ma il server che lo deve ricevere è fermo per un aggiornamento. Il messaggio non trova nessuno. Alcuni mittenti riprovano dopo un po', per qualche tentativo, poi rinunciano. Altri non riprovano affatto. Il lunedì il cliente chiede dov'è la merce, e nel gestionale quell'ordine non esiste.
Le cause ricorrenti sono poche:
- il programma che riceve era spento, in aggiornamento o sovraccarico;
- l'indirizzo è cambiato (migrazione, nuovo sito, nuovo strumento) e nessuno ha aggiornato il mittente;
- il ricevente ha risposto troppo lentamente e il mittente ha considerato il messaggio fallito;
- il messaggio è arrivato due volte, e l'ordine è stato creato due volte.
L'ultimo caso è il più sottovalutato. Se il mittente non riceve conferma in tempo, rimanda. Un'automazione fatta bene riconosce che quel messaggio l'ha già visto. Una fatta male raddoppia la spedizione.
Che cosa conviene fare, in pratica? Non cercare un webhook che non si perde mai: non esiste. Costruisci il resto in modo che la perdita si veda e si recuperi.
- Un controllo di quadratura. Una volta al giorno confronta gli ordini di ieri nello strumento di origine con quelli arrivati a destinazione. Se i numeri non coincidono, parte un avviso a una persona, non a una casella che nessuno apre.
- Un registro dei messaggi ricevuti. Anche solo una riga per ogni arrivo, con ora ed esito. Quando qualcuno dice «non mi è arrivato», hai dove guardare.
- Una risposta rapida. Il ricevente conferma subito e fa il lavoro pesante dopo. Così il mittente non rimanda per impazienza.
- Un riconoscimento dei doppioni. Di solito ogni messaggio porta un identificativo: se l'hai già visto, lo scarti.
- Una strada per recuperare. Alcuni strumenti permettono di rimandare i messaggi di un intervallo di tempo. Sapere se il tuo lo fa, e dove si trova quel pulsante, vale più di qualsiasi promessa del fornitore.
Un indirizzo aperto: chi può mandarti messaggi finti
L'indirizzo che incolli nel programma mittente è raggiungibile da internet. Se qualcuno lo scopre, può spedirti un messaggio costruito a mano: un ordine che non è mai stato pagato, per esempio. Molti mittenti firmano i messaggi con una chiave condivisa che il ricevente può controllare; dove c'è, usala. Dove non c'è, non lasciare l'indirizzo in giro e non trattare un messaggio come prova di pagamento senza verificare sul sistema che lo ha generato. Anche qui il controllo di quadratura ti copre.
Come provarne uno senza scrivere codice
Non serve uno sviluppatore per fare il primo esperimento. Strumenti come n8n (ne abbiamo parlato in n8n cos'è e quando conviene rispetto al codice) ti danno un indirizzo pronto da incollare nello strumento che invia. Attenzione a un dettaglio: n8n distingue un indirizzo di prova, che ascolta solo mentre stai guardando, e uno di produzione, che funziona solo a flusso attivato. Per l'uso reale serve il secondo. La procedura, per un primo test:
- Scegli un evento semplice e poco critico, per esempio una richiesta dal modulo del sito.
- Crea nello strumento di automazione un punto di ascolto: ti restituisce un indirizzo web.
- Incolla quell'indirizzo nelle impostazioni del sito o del programma che deve avvisare.
- Genera tu stesso un evento di prova e guarda il messaggio arrivare. Leggerlo con i tuoi occhi, con i campi che contiene, ti insegna più di qualsiasi spiegazione.
- Collega un'azione minima, come una riga in un foglio di calcolo o una notifica a un collega.
- Disattiva il flusso per un po' e rifai la prova. Vedere cosa si perde ti dice se il mittente riprova da solo.
Quest'ultimo passaggio è quello che quasi nessuno fa, ed è il più istruttivo.
Quando il webhook non è la risposta
Non tutti i programmi ne offrono uno. I gestionali più datati spesso non hanno nulla del genere, e lì puoi ricorrere a un controllo periodico ogni pochi minuti: meno elegante, ma robusto, e per molti processi più che sufficiente. Se non c'è nemmeno un'API, l'ultima risorsa è un robot che clicca al posto di una persona: abbiamo messo i pro e i contro in RPA cos'è, quando il robot che clicca serve e quando basta un'API.
Il criterio per scegliere è questo: se un ritardo di qualche minuto ti è indifferente, il controllo periodico è spesso più sicuro, perché non dipende dal fatto che il messaggio arrivi. Se un ritardo costa (un cliente che aspetta, una giacenza che si vende due volte), il webhook è la strada giusta, ma con il controllo di quadratura accanto.
Prendi un foglio e scrivi tre righe per un'operazione che oggi fai a mano ogni volta che succede qualcosa: che cosa succede, dove devono finire le informazioni, chi si accorge se non arrivano. Se non sai rispondere all'ultima, il webhook non è ancora pronto da costruire.
Domande frequenti
Un webhook è la stessa cosa di un'API?
No. Con l'API chiedi tu un'informazione quando ti serve; con il webhook è il programma che ti avvisa appena succede qualcosa. Spesso si usano insieme nella stessa automazione.
Cosa succede se un webhook non arriva?
Dipende dal mittente: alcuni riprovano più volte, altri rinunciano subito. Non compare nessun errore visibile, quindi serve un controllo quotidiano che confronti quanto è successo all'origine con quanto è arrivato a destinazione.
Serve saper programmare per usare un webhook?
Per un primo uso no: strumenti come n8n ti danno un indirizzo da incollare nel programma che invia. Per i casi che toccano ordini, pagamenti o clienti conviene far controllare la gestione degli errori a chi costruisce l'automazione.