Finora, sapere se un post era uscito significava chiedere. Chiamavi l'API, controllavi lo stato e richiamavi più tardi. Funziona, ma è un'interrogazione continua: o chiedi troppo spesso e sprechi richieste, o chiedi troppo di rado e lo scopri tardi. I webhook ribaltano la logica. Dai un URL a sona.to, e sona.to ti chiama nel momento in cui succede qualcosa. Sono disponibili da subito su tutti i piani.
Ci sono quattro eventi a cui iscriversi, e coprono i casi che meritano una reazione: post pubblicato, post fallito, audit del sito completato e audit del sito fallito. Scegli tu quali riceve ogni webhook, così un avviso su Slack può ascoltare solo i fallimenti mentre un sistema di reportistica prende tutto. Il payload usa gli stessi nomi di campo restituiti dall'API REST, quindi ciò che già analizzi da una richiesta GET continua a funzionare senza modifiche.
Configurarlo richiede un minuto. Apri la pagina API della tua dashboard, incolla l'URL che ti ha dato il tuo strumento, spunta gli eventi che vuoi e salva. La chiave di firma compare una sola volta in quel momento. Copiala subito, perché non viene più mostrata.
Quella chiave è ciò che ti permette di sapere che una richiesta è autentica. Ogni consegna porta un header di firma con un timestamp e un HMAC SHA-256 di quel timestamp e del corpo della richiesta, calcolato con la tua chiave. Ricalcolalo dalla tua parte e confronta i due valori con una funzione a tempo costante. Poiché il timestamp fa parte del materiale firmato, una richiesta intercettata non può essere riprodotta contro di te in seguito. Rifiuta tutto ciò che ha più di qualche minuto e hai finito.
Le consegne non si arrendono al primo problema. Se il tuo endpoint è irraggiungibile o restituisce un errore, la richiesta viene ritentata dopo 60 secondi, poi 5 minuti, poi 30 minuti. Ogni tentativo viene registrato con il suo codice di stato e la sua durata, così un endpoint che si comporta male è qualcosa che puoi esaminare invece di indovinare. Un endpoint che continua a fallire viene disattivato automaticamente, e puoi riattivarlo una volta sistemato.
Il posto ovvio verso cui puntarlo è una piattaforma di automazione. Zapier, Make e n8n ti danno tutti un URL webhook da incollare, e l'evento arriva in JSON pronto da collegare a ciò che viene dopo: un messaggio in un canale, una riga in un foglio di calcolo, un'attività in un gestionale. Il tuo server funziona esattamente allo stesso modo, senza piattaforme di mezzo.
Una nota su cosa accetta sona.to. La destinazione deve usare https e deve essere un indirizzo pubblico. Un URL che punta a una rete privata viene rifiutato, sia al salvataggio sia al momento della consegna, e i reindirizzamenti non vengono seguiti. Se ospiti un ricevitore su una rete locale, mettilo dietro un nome host pubblico o un tunnel.
I webhook si affiancano all'API REST e al server MCP come terzo modo di guidare sona.to da fuori la dashboard. L'API serve per chiedere, MCP per farsi chiedere da un assistente IA, e i webhook per essere avvisati. Tutti i dettagli, incluso un esempio di verifica della firma, sono nella documentazione dell'API.