Tu as branché ton webhook, le test passe, et tu veux savoir ce que tu vas recevoir avant d'écrire le code qui le consomme.

Un seul événement métier existe : call.available. Il part quand l'analyse d'un appel se termine, une seule fois par appel. Le bouton Envoyer un test émet en plus un webhook.test vers la même URL, à prévoir côté serveur.

Voici sa forme exacte.

L'enveloppe

Description de la section Webhooks.

{
  "id": "wev_3f9c1a2e-...",
  "type": "call.available",
  "created_at": "2026-07-21T12:00:00.000Z",
  "data": { }
}

Quatre clés, toujours les mêmes.

id est l'identifiant d'événement. Il est stable entre les tentatives et se retrouve dans l'en-tête X-Eagr-Event-Id. C'est ta clé de déduplication.
type vaut call.available. L'événement de test, lui, porte webhook.test.
created_at est l'horodatage de validation de l'appel, pas celui de l'envoi. Sur une relivraison six heures plus tard, il ne bouge pas.
data contient l'appel.

Il n'y a pas de champ de version. Prévois ton code pour ignorer les clés inconnues.

Ce que contient data

Le bloc décrit l'appel tel que son propriétaire le voit dans Eagr.

Champ	Type	Contenu
`id`	texte	Identifiant de l'appel, préfixé `rcs_`
`status`	texte	Vaut `validated` sur cet événement
`provider`	texte	Source de l'enregistrement, par exemple `eagr_webhook` ou `aircall`
`score`	nombre	Score global arrondi, sur 100
`percentageScore`	nombre	Le même score, à deux décimales
`durationSeconds`	nombre ou null	Durée de l'appel
`title`	texte ou null	Titre de l'appel
`callOutcome`	texte ou null	Issue de l'appel
`category`	texte ou null	`analyzed`, `internal`, `other`, `not_relevant` ou `no_speech`
`categoryConfidence`	nombre ou null	Confiance de la classification, de 0 à 1
`segmentConfidence`	nombre ou null	Confiance du segment, de 0 à 1
`topScore`	booléen	L'appel est signalé comme un top call
`recordUrl`	texte ou null	URL signée de l'enregistrement, à durée limitée
`url`	texte ou null	URL de l'appel chez l'enregistreur d'origine
`providerCallId`	texte ou null	Identifiant de l'appel chez l'enregistreur
`transcriptionId`	texte ou null	Identifiant de transcription
`userId`	texte	Propriétaire de l'appel, préfixé `usr_`
`clientId`	texte ou null	Organisation, préfixé `cli_`
`isPrivate`	booléen	Toujours `false` sur cet événement
`createdAt`	texte	Date de création, au format ISO
`updatedAt`	texte	Date de dernière modification, au format ISO
`feedbackRelevant`	booléen ou null	Retour donné sur la pertinence de l'analyse
`relevantAnalysis`	booléen ou null	L'analyse a été jugée pertinente
`runId`	texte ou null	Identifiant du traitement d'analyse
`v2`	booléen ou null	L'appel est passé par la chaîne d'analyse v2
`v3`	booléen ou null	L'appel est passé par la chaîne d'analyse v3
`errorMessage`	texte ou null	Message d'erreur du dernier traitement

Ces six derniers champs sont toujours présents dans la charge utile. Un schéma strict qui ne les déclare pas casse à la première livraison.

Trois champs supplémentaires portent l'analyse.

results contient le détail de l'analyse : segments, compétences, techniques et scores.
scorecard nomme la grille utilisée.
callInsights est un tableau, chaque entrée ayant un id préfixé cin_, un type, un content, un bloc metadata et une date de création. Les plus récents d'abord.

Ce que l'événement ne contient jamais

Cette liste est verrouillée par un test automatique côté produit. Ces champs n'y figurent pas, quelles que soient les circonstances :

le transcript et le texte de l'appel,
les interlocuteurs et la chronologie de prise de parole,
les coordonnées de contact et le contexte externe,
les indicateurs additionnels,
l'objet utilisateur complet et l'objet organisation complet,
le journal de classification, réservé à l'administration Eagr.

Pour le transcript, appelle l'API avec l'identifiant reçu.

Comment récupérer le reste

L'identifiant rcs_ est ta clé d'entrée. Depuis l'API, GET /api/v2/real-case-sessions/{id} te rend le détail, et /api/v1/real-case/{id}/transcript le transcript normalisé avec ses interlocuteurs.

L'authentification se fait avec un token API. Voir « Comment générer un token API Eagr ».

Que se passe-t-il si la charge utile est trop grosse

Au-delà de 256 Ko, Eagr n'envoie pas le détail. Le bloc data est remplacé par un pointeur :

{
  "id": "wev_3f9c1a2e-...",
  "type": "call.available",
  "created_at": "2026-07-21T12:00:00.000Z",
  "data": {
    "id": "rcs_...",
    "url": "https://app.eagr.ai/api/v2/real-case-sessions/rcs_..."
  }
}

Ton code doit gérer les deux formes. Le plus robuste est de ne jamais dépendre du contenu de data et de toujours recharger l'appel par son identifiant.

À quoi ressemble l'événement de test

Il porte le type webhook.test, un identifiant préfixé wev_test_, et une charge utile fixe qui contient un titre Test webhook delivery, un statut validated, et une note précisant qu'il ne transporte aucune donnée d'appel réelle.

Il est signé exactement comme un vrai événement, avec les trois mêmes en-têtes. Il ne lit rien en base : un test ne peut pas exposer un appel à une URL arbitraire.

Quand l'événement ne part pas

L'appel n'a pas été analysé
L'événement part au moment où l'appel passe à l'état validé. Un appel en erreur, sans parole détectée ou classé hors périmètre ne produit rien.

L'appel est privé
Aucun événement, jamais. C'est le même principe que pour les emails : un événement révélerait son existence.

Aucun webhook actif n'existait au moment de l'analyse
Le comportement est strictement en avant : un webhook créé aujourd'hui ne reçoit pas les appels validés hier. Rien n'est mis en file d'attente pour plus tard.

Le propriétaire de l'appel sort de ton périmètre
Un webhook personnel ne livre que les appels que son créateur peut voir. Si le propriétaire n'est pas dans ce périmètre, l'événement existe mais ne t'est pas livré.

Le compte propriétaire du webhook a été révoqué
Plus rien n'est livré sur ce webhook. C'est un choix de sécurité, pas une panne.

Ce que ça ne fait pas

L'événement n'est pas rejoué. Relancer une analyse ne le réémet pas, même si le score change. Un appel produit au plus un call.available, une fois pour toutes.

Il n'existe pas d'autre événement métier. Ni à la création de l'appel, ni pendant la transcription, ni sur une modification ultérieure. Seul webhook.test, déclenché par le bouton Envoyer un test, atteint aussi ton endpoint.

Et l'URL d'enregistrement contenue dans recordUrl expire. Télécharge le média sans attendre, ou recharge l'appel par l'API au moment où tu en as besoin.

Que contient l'événement call.available