type dont la valeur est l’un des types
d’événements de cette page. Lorsque vous vous abonnez à un
endpoint, le tableau events doit contenir les
types d’événements souhaités (ou être vide pour vous abonner à tous les événements).
Ces événements sont transmis selon deux modes :
- Les livraisons d’endpoint sont toujours des notifications non bloquantes
avec des tentatives : répondez avec
n’importe quel code 2xx ; l’enveloppe contient un
event_idà utiliser pour la déduplication. - Les échanges bloquants s’exécutent uniquement sur le
webhook historique à URL unique : la requête de
configuration
telephony.incoming/web.incoming(numéros en mode webhook et clés de widget, délai d’expiration de 10 s) et la répartition des outils en mode webhook. Votre réponse façonne l’appel en direct.
data, event_id, type) ;
les livraisons historiques contiennent les mêmes data sans event_id.
Événements d’appel
telephony.incoming
Envoyé lorsqu’un appel entrant atteint l’un de vos
numéros de téléphone. Les livraisons aux endpoints sont des
notifications sans attente de réponse envoyées pour chaque appel entrant, que
le numéro soit configuré avec un agent ou avec un webhook. Les numéros sans
agent attribué reçoivent également la requête de configuration bloquante
sur le webhook hérité — consultez
telephony.incoming / web.incoming pour
le schéma complet de requête / réponse.
telephony.complete
Envoyé lorsqu’un appel téléphonique entrant ou sortant se termine. Non bloquant.
Inclut la transcription complète, l’URL de l’enregistrement et le récapitulatif
de facturation. Consultez
telephony.complete / web.complete pour
le schéma de la charge utile.
telephony.tool
Envoyé après qu’un appel téléphonique a invoqué un
outil de fonction. Notification d’audit non bloquante —
l’outil a déjà été exécuté lorsque cet événement est livré ; il couvre
vos propres outils de fonction (et non les outils intégrés, de base de connaissances,
de connexion d’application ou MCP).
response correspond au résultat exécuté : {"status": <http status>, "response": <your endpoint's JSON>} en cas de réussite, ou
{"status": <status>, "error": "<message>"} en cas d’échec.
web.incoming
L’équivalent de telephony.incoming pour le canal web, envoyé lorsqu’une
session de widget web ou un appel de test du micro dans le builder
démarre. Les livraisons aux endpoints sont sans attente de réponse pour chaque session web.
Les clés publiables en mode="webhook" reçoivent également la requête de
configuration bloquante sur le webhook hérité — cette requête bloquante
a une structure différente (origin_domain,
publishable_key_prefix ; aucun numéro de téléphone). Consultez
telephony.incoming / web.incoming.
from_number correspond toujours à la valeur littérale "web". Pour les sessions
de widget en mode webhook, to_number est vide (le numéro d’agent de la session est attribué
après la configuration) ; pour les appels de test du micro dans le builder, origin_domain et
publishable_key_prefix sont vides.
web.complete
L’équivalent de telephony.complete pour le canal web, couvrant les appels de
widget web (direction: "web") et les appels de test du micro dans le builder
(direction: "test"). Non bloquant. Même structure de charge utile que
telephony.complete, avec origin_domain en plus,
et from_number défini sur "web".
Sur le webhook hérité à URL unique, les appels de test du micro dans le builder
sont historiquement signalés comme
telephony.complete — seuls les appels avec
direction: "web" y utilisent le type web.complete. Le système d’endpoints
mappe les appels web et de test vers web.*. Les charges utiles historiques peuvent
contenir les anciennes valeurs widget ou mic pour direction.web.tool
L’équivalent de telephony.tool pour le canal web. Les data contiennent
origin_domain au lieu de from_number / to_number.
Événements de qualité
call.graded
Envoyé lorsqu’une exécution d’évaluation par IA
se termine pour un appel. Non bloquant.
Un appel peut être évalué plusieurs fois — une évaluation heuristique rapide est
souvent suivie d’une évaluation complète par modèle une fois l’enregistrement
disponible, et des réévaluations manuelles sont possibles. Chaque exécution
terminée émet son propre événement
call.graded ; considérez le dernier
graded_at comme faisant autorité.issue.reported
Envoyé lorsqu’un rapport de problème est créé —
soit signalé par un utilisateur depuis le tableau de bord (source: "user"), soit
automatiquement par l’évaluation d’appel (source: "system"). Non bloquant.
La réévaluation d’un appel reconstruit ses rapports de problèmes générés par le
système, ce qui émet à nouveau
issue.reported pour les rapports recréés.
Dédupliquez sur call_id + title si vous ne souhaitez qu’une notification par
problème sous-jacent.Événements d’appels de test
test-call.completed
Envoyé lorsqu’une
exécution d’appel de test
atteint un statut terminal — completed ou failed, y compris les exécutions
qui ont échoué au lancement et n’ont jamais produit d’appel. Non bloquant. Utile
pour connecter les exécutions CI par lot à vos systèmes de chat/notifications.
Événements d’alerte
alert.triggered
Envoyé lorsqu’une règle d’alerte dont le canal Transmettre aux
webhooks de développeur est activé franchit son seuil.
Non bloquant. Une règle se déclenche une fois, puis respecte son délai de
refroidissement ; une violation persistante produit donc un événement par fenêtre de délai de refroidissement.
Consultez le guide des alertes pour créer des règles, configurer les métriques,
les délais de refroidissement et les canaux e-mail / Slack.
Associé
telephony.incoming / web.incoming
La charge utile bloquante des appels entrants à laquelle vous devez répondre.
telephony.complete / web.complete
Transcription et métriques après l’appel.
Points de terminaison webhook
Abonnez une URL à un sous-ensemble de ces événements.
Outils de fonction
Comment les événements
telephony.tool / web.tool sont générés.