Skip to main content
Ogni corpo del webhook ha un campo type il cui valore è uno dei tipi di evento in questa pagina. Quando ti iscrivi a un endpoint, l’array events deve contenere i tipi di evento desiderati (oppure essere vuoto per iscriverti a tutti). Questi eventi vengono inviati in due modalità:
  • Le consegne agli endpoint sono sempre notifiche non bloccanti con ritenti: rispondi con qualsiasi 2xx; l’involucro contiene un event_id per la deduplicazione.
  • Gli scambi bloccanti vengono eseguiti solo sul webhook legacy a URL singolo: la richiesta di configurazione telephony.incoming / web.incoming (numeri in modalità webhook e chiavi widget, timeout di 10 s) e l’invio di strumenti in modalità webhook. La tua risposta modella la chiamata in corso.
Gli esempi di payload seguenti mostrano l’involucro dell’endpoint nell’ordine di trasmissione (chiavi ordinate alfabeticamente: data, event_id, type); le consegne legacy includono gli stessi data senza event_id.

Eventi di chiamata

telephony.incoming

Inviato quando una chiamata in entrata raggiunge uno dei tuoi numeri di telefono. Le consegne agli endpoint sono notifiche fire-and-forget inviate per ogni chiamata in entrata, indipendentemente dal fatto che il numero sia configurato con un agente o con un webhook. I numeri senza un agente assegnato ricevono inoltre la richiesta di configurazione bloccante sul webhook legacy — consulta telephony.incoming / web.incoming per lo schema completo di richiesta / risposta.

telephony.complete

Inviato al termine di una chiamata telefonica in entrata o in uscita. Non bloccante. Include la trascrizione completa, l’URL della registrazione e il riepilogo della fatturazione. Consulta telephony.complete / web.complete per lo schema del payload.

telephony.tool

Inviato dopo che una chiamata telefonica richiama uno strumento funzione. Notifica di audit non bloccante — lo strumento è già stato eseguito quando questo evento viene consegnato; riguarda i tuoi strumenti funzione (non gli strumenti integrati, della knowledge base, delle connessioni app o MCP).
response è il risultato dell’esecuzione: {"status": <http status>, "response": <your endpoint's JSON>} in caso di successo oppure {"status": <status>, "error": "<message>"} in caso di errore.

web.incoming

L’equivalente del canale web di telephony.incoming, inviato quando inizia una sessione di widget web o una chiamata di test del microfono nel builder. Le consegne agli endpoint sono fire-and-forget per ogni sessione web. Le chiavi pubblicabili in mode="webhook" ricevono inoltre la richiesta di configurazione bloccante sul webhook legacy — tale richiesta bloccante ha una struttura diversa (origin_domain, publishable_key_prefix; nessun numero di telefono). Consulta telephony.incoming / web.incoming.
from_number è sempre il valore letterale "web". Per le sessioni del widget in modalità webhook, to_number è vuoto (il numero dell’agente della sessione viene assegnato dopo la configurazione); per le chiamate di test del microfono nel builder, origin_domain e publishable_key_prefix sono vuoti.

web.complete

L’equivalente del canale web di telephony.complete, che copre le chiamate del widget web (direction: "web") e le chiamate di test del microfono nel builder (direction: "test"). Non bloccante. Stessa struttura del payload di telephony.complete, più origin_domain, con from_number impostato su "web".
Sul webhook legacy con URL singolo, le chiamate di test del microfono nel builder vengono storicamente segnalate come telephony.complete — solo le chiamate con direction: "web" utilizzano qui il tipo web.complete. Il sistema degli endpoint mappa sia le chiamate web sia quelle di test su web.*. I payload storici possono contenere i valori legacy di direction widget o mic.

web.tool

L’equivalente del canale web di telephony.tool. data contiene origin_domain anziché from_number / to_number.

Eventi di qualità

call.graded

Inviato ogni volta che un’esecuzione di valutazione AI viene completata per una chiamata. Non bloccante.
Una chiamata può essere valutata più di una volta — una valutazione euristica rapida è spesso seguita da una valutazione completa del modello una volta che la registrazione è disponibile, e sono possibili rivalutazioni manuali. Ogni esecuzione completata emette il proprio evento call.graded; considera autorevole il valore graded_at più recente.

issue.reported

Inviato quando viene creata una segnalazione di problema — inviata da un utente dalla dashboard (source: "user") oppure automaticamente dalla valutazione della chiamata (source: "system"). Non bloccante.
Rivalutare una chiamata ricrea le relative segnalazioni di problema generate dal sistema, emettendo nuovamente issue.reported per le segnalazioni ricreate. Esegui la deduplicazione in base a call_id + title se vuoi ricevere una sola notifica per ogni problema sottostante.

Eventi delle chiamate di test

test-call.completed

Inviato quando un’esecuzione di chiamata di test raggiunge uno stato terminale — completed o failed, incluse le esecuzioni che non sono riuscite all’avvio e non hanno mai prodotto una chiamata. Non bloccante. Utile per collegare esecuzioni CI batch ai sistemi di chat/notifiche.

Eventi di avviso

alert.triggered

Inviato quando una regola di avviso con il canale Invia ai webhook per sviluppatori abilitato supera la propria soglia. Non bloccante. Una regola scatta una sola volta e poi rispetta il proprio periodo di cooldown, quindi una violazione persistente produce un evento per ogni finestra di cooldown.
Consulta la guida agli avvisi per creare regole, metriche, periodi di cooldown e canali email / Slack.

Correlati

telephony.incoming / web.incoming

Il payload bloccante della chiamata in entrata a cui devi rispondere.

telephony.complete / web.complete

Trascrizione e metriche post-chiamata.

Endpoint webhook

Sottoscrivi un URL a un sottoinsieme di questi eventi.

Strumenti funzione

Come vengono generati gli eventi telephony.tool / web.tool.