Skip to main content
Chaque corps de webhook contient un champ 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.
Les exemples de payloads ci-dessous montrent l’enveloppe d’endpoint dans son ordre de transmission (clés triées par ordre alphabétique : 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.