Ton endpoint est en ligne, ton webhook est créé, et ton journal serveur est vide depuis trois jours.
Avant de fouiller tes logs, regarde ce qu'Eagr dit de ses propres livraisons. La colonne Dernière livraison répond à la première question, celle de savoir si quelque chose est seulement parti.
Ce qu'il te faut avant de commencer
Un endpoint en https. Le produit le demande explicitement : « Saisissez une URL https. »
Le secret de signature, copié à la création. Il n'est affiché qu'une fois.
La possibilité de lire les requêtes entrantes de ton service, y compris celles que tu as rejetées.
1. Lis l'état de la dernière livraison
Page Paramètres puis Connexions avec la sidebar.
Paramètres puis Connexions, section Webhooks. Il n'y a pas d'entrée de menu Webhooks : les webhooks vivent dans la page Connexions. La colonne Dernière livraison affiche l'un de ces cinq états :
En attente du premier appel, rien n'a encore été tenté.
En cours, une livraison est en route.
Livré, ton endpoint a répondu correctement.
Échec, la dernière tentative a échoué.
Non livré, Eagr a renoncé après ses tentatives.
En attente du premier appel est le cas le plus fréquent quand on croit à une panne. Aucun appel analysé ne s'est encore présenté, il n'y a rien à réparer.
2. Envoie un test
Section Webhooks.
Bouton Envoyer un test. Eagr répond « Événement de test livré » si ton endpoint a accepté, ou « Échec du test » suivi du code HTTP renvoyé.
Ce code est l'information la plus utile de toute la page. Un 401 ou un 403 dit que ta vérification de signature rejette le message. Un 404 dit que l'URL est mauvaise. Un 500 dit que ton code casse sur le format du payload.
Ne spamme pas le bouton : « Trop de tests envoyés. Attendez une minute et réessayez. »
3. Vérifie ta signature
Dialogue Ajouter un webhook et sa description complète.
C'est la cause la plus fréquente de webhook qui « ne reçoit rien » alors qu'Eagr livre correctement : ton serveur reçoit, rejette, et ne journalise pas le rejet.
Eagr décrit la vérification mot pour mot : « calculez le HMAC-SHA256 de l'horodatage, un point, puis le corps brut, avec ce secret complet comme clé (préfixe whsec_ inclus), et comparez-le à l'en-tête X-Eagr-Signature ».
Trois pièges dans cette phrase :
Le corps brut. Pas le JSON reparsé puis resérialisé. Beaucoup de frameworks parsent le corps avant que tu puisses le lire, et la signature ne correspond plus.
Le secret complet. Le préfixe
whsec_fait partie de la clé, il ne se retire pas.Le point. L'horodatage, un point littéral, puis le corps. Pas de deux-points, pas d'espace.
Chaque requête porte trois en-têtes de signature : X-Eagr-Signature, X-Eagr-Timestamp et X-Eagr-Event-Id. Le Content-Type: application/json habituel s'y ajoute. La signature est en hexadécimal. Prévois une tolérance d'horloge de 300 secondes sur l'horodatage, et sers-toi de l'identifiant d'événement pour ignorer les doublons.
4. Vérifie que le webhook est activé
La colonne Activé porte un interrupteur, et l'action s'appelle Activer ou désactiver. Un webhook désactivé reste dans la liste sans rien envoyer.
Quel événement Eagr envoie-t-il
Un seul événement métier : call.available, quand l'analyse d'un appel se termine. Le produit le formule ainsi : « Soyez notifié à votre propre URL quand l'analyse d'un appel se termine. »
Le bouton Envoyer un test émet en plus un webhook.test. Prévois-le côté serveur, sinon ton endpoint rejettera le test que tu viens de déclencher.
N'attends rien d'autre : ni à la création de l'appel, ni pendant la transcription, ni sur un changement de score ultérieur.
Pourquoi je reçois moins d'événements que d'appels
Le dialogue de création contient la réponse, et elle passe souvent inaperçue : Eagr envoie l'événement « quand l'analyse d'un appel que vous pouvez voir se termine ».
La portée du webhook est donc bornée par tes droits. Un webhook de portée personnelle ne voit que tes appels. Un webhook d'organisation, marqué Org, couvre l'organisation.
Et un appel non analysé ne produit aucun événement. Un appel plus court que la durée minimale d'analyse ne déclenche rien. Ce seuil est réglé par ton administrateur dans Paramètres puis Règles d'analyse, 3 minutes par défaut, et il peut être relevé segment par segment.
Le dépassement du nombre de participants coupe l'événement lui aussi. Un appel à plus de 6 participants n'est pas analysé : il ne produit donc aucun événement, comme tout appel non analysé. Le rattachement au deal et la notification, eux, ont bien lieu. Le maximum vaut 6 participants par défaut, ton administrateur le règle dans Paramètres puis Règles d'analyse. Le test est strict : un appel qui atteint exactement le maximum passe.
J'ai perdu mon secret de signature
Il n'est pas récupérable. L'avertissement est affiché à la création : « Copiez votre secret de signature maintenant. Il ne sera plus affiché. »
Supprime le webhook et recrée-le. Tu obtiendras un nouveau secret, à déployer côté serveur avant de réactiver.
Bonne nouvelle si tu changes seulement de destination : Modifier l'URL conserve le secret. Le produit le précise, « Le secret de signature reste identique. »
Combien de fois Eagr réessaie
Six tentatives au total : la première, puis cinq relivraisons espacées de 1 minute, 5 minutes, 30 minutes, 2 heures et 6 heures. Budget épuisé, la livraison passe Non livré et cet événement est perdu.
Ce qui déclenche une relivraison : un code 408, un 429, tout 5xx, ou une absence de réponse. Ce qui n'en déclenche aucune : tout autre 4xx, considéré comme une erreur définitive de ton côté.
Réponds en 2xx et en moins de 10 secondes. Au-delà, la livraison est comptée comme un échec.
Un dernier détail qui piège : une redirection 3xx n'est jamais suivie. Elle est traitée comme un échec définitif. Donne l'URL finale, pas une redirection.
Rien ne marche, même le test
Le message « Les webhooks ne sont pas encore configurés sur ce serveur. Contactez le support. » s'affiche
La fonctionnalité n'est pas activée sur ton environnement. Rien à faire de ton côté, écris à [email protected].
Ton endpoint répond trop lentement
Le délai est de 10 secondes. Accuse réception immédiatement et traite le message en tâche de fond, ne fais jamais ton traitement métier dans la requête.
Un pare-feu bloque les requêtes entrantes
Classique sur un environnement de préproduction. Teste avec un service de réception public avant d'accuser Eagr.
Ton certificat TLS n'est pas valide
Un certificat expiré ou auto-signé fait échouer la connexion avant même le POST. Aucun message ne te le dira côté Eagr.
Pourquoi je ne reçois rien sur les appels privés
Par construction. Un appel privé ne produit aucun événement webhook, jamais. C'est le même principe que pour les alertes : un événement révélerait son existence.
Ce que ça ne fait pas
Un webhook n'est pas un flux d'export. Il ne rejoue pas l'historique, et un endpoint créé aujourd'hui ne recevra jamais les appels analysés hier.
L'événement n'est émis qu'une seule fois par appel. Relancer une analyse ne le réémet pas, même si le score change.
Les charges utiles dépassant 256 Ko ne sont pas envoyées entières : Eagr envoie à la place une enveloppe contenant l'identifiant et une URL à appeler pour récupérer le détail. Prévois ce cas dans ton code.
Et un webhook ne remplace pas l'API. Pour lire des données à la demande, ce sont les Tokens API ou le serveur MCP qu'il te faut.
À lire ensuite : « Comment connecter Claude ou Cursor à Eagr », « Pourquoi mon appel ne remonte pas ou n'est pas analysé ».