Événements
La v1 compte trois événements :
Quand un échec fait disparaître une automatisation — accès au compte révoqué, boîte mail qui refuse la connexion, canal impossible à reconnecter — l’automatisation sort de l’API et un dernier Statut d’automatisation modifié avec le statut
error est envoyé : quand il arrive, chercher l’automatisation par son ID répond automation_not_found. Supprimer une automatisation ou la désactiver dans l’application Agentova n’envoie rien.
Voir Concepts pour les sources de leads et les exécutions produites par chaque canal.
S’abonner
POST /webhooks avec une url et les events voulus (au moins un). La réponse contient un secret — affiché une seule fois, à la création. Conservez-le : c’est lui qui vous sert à vérifier chaque livraison de cet abonnement. Chaque abonnement a son propre secret.
L’url doit :
- utiliser HTTPS ;
- pointer vers une adresse publique — les adresses locales, privées et de métadonnées cloud sont refusées, et le nom d’hôte doit se résoudre ;
- ne contenir ni nom d’utilisateur ni mot de passe.
400 invalid_request avec details.parameter: "url" et une details.reason (https_required, private_address, local_address, credentials_in_url, unresolvable_host…).
Un espace de travail peut avoir 20 abonnements actifs. GET /webhooks les renvoie tous d’un coup, sans pagination — avec les abonnements désactivés, jusqu’à leur suppression (voir plus bas). Elle ne renvoie l’url complète que pour les abonnements créés avec la clé qui fait l’appel ; pour les autres, url est réduite à son origine (par exemple https://hooks.zapier.com), car le chemin d’une adresse de webhook contient le jeton secret du connecteur.
Les abonnements appartiennent à l’espace de travail : n’importe quelle clé de l’espace de travail peut les lister et les supprimer. Révoquer une clé supprime les abonnements créés avec elle, sauf si l’administrateur choisit de les garder — voir Révoquer une clé. Les administrateurs de l’espace de travail voient et peuvent supprimer tous les abonnements dans le tableau Abonnements webhook de Paramètres → API.

Abonnements webhook : une ligne par abonnement, avec la clé qui l'a créé
La livraison
Chaque événement est livré par unPOST à l’URL de l’abonnement, avec ces en-têtes :
Le corps est une enveloppe JSON :
data dépend de type : un lead pour lead.created, une exécution pour run.completed, une automatisation pour automation.status_changed — les mêmes objets que ceux renvoyés par GET /leads, GET /runs et GET /automations.
- Au moins une fois. Un même événement peut être livré plusieurs fois, après un nouvel essai par exemple. Dédoublonnez sur
id: il est unique par événement, identique à chaque tentative, et le même pour tous les abonnements qui reçoivent l’événement. Gardez les identifiants déjà vus pendant au moins 48 heures : les nouveaux essais sont toujours programmés dans les 36 heures qui suivent la création de l’événement. - Sans ordre garanti. Deux événements peuvent arriver dans n’importe quel ordre — une pause et la réactivation qui la suit, par exemple. Pour les ordonner, utilisez l’horodatage de la ressource elle-même —
updated_atpour une automatisation,created_atpour un lead,occurred_atpour une exécution —, pas l’ordre d’arrivée.
Vérifier la signature
Chaque livraison porte un en-têteX-Agentova-Signature :
t— le moment où cette tentative de livraison a été signée, en horodatage Unix (secondes)v1— le HMAC-SHA256 de la chaîne{t}.{corps brut}, en hexadécimal minuscule
whsec_ compris. Certaines bibliothèques de webhooks — celles qui suivent la convention Standard Webhooks — retirent un préfixe whsec_ et décodent ce qui suit : ne les utilisez pas telles quelles. Chez Agentova, le préfixe fait partie de la clé.
C’est la signature qui authentifie une livraison. Ne filtrez pas les livraisons par adresse IP ni par User-Agent : Agentova ne publie pas de liste d’adresses d’origine, et n’importe qui peut envoyer ce User-Agent.
Pour vérifier une livraison :
- Lisez le corps brut, exactement tel que reçu, avant toute analyse JSON — un corps analysé puis resérialisé ne produit pas les mêmes octets.
- Rejetez-la si
ts’écarte de plus de 5 minutes de votre heure actuelle. Cela bloque les requêtes rejouées. - Calculez le HMAC-SHA256 de
{t}.{corps brut}avec le secret complet, et comparez-le àv1en temps constant — jamais avec==ou===, qui laissent fuiter des informations de temps.
Les connecteurs officiels vérifient les signatures pour vous : avec le nœud n8n ou l’app Zapier, cette section ne vous concerne pas. L’app Zapier accepte des signatures vieilles d’une heure au plus, car Zapier peut traiter une notification avec du retard et son adresse de notification est déjà secrète. Pour votre propre route, gardez 5 minutes.
Vecteur de test
Vérifiez votre implémentation avec ces valeurs avant la mise en service :Corps brut
1790856000, votre fonction doit renvoyer true. Elle doit renvoyer false quand un caractère du corps change, quand l’heure actuelle s’écarte de plus de 300 secondes de t, et quand le secret est utilisé sans son préfixe whsec_.
Reproduire le vecteur depuis un terminal
Reproduire le vecteur depuis un terminal
cc0aeaeeb19b6d50d7c200ece4653adfba91c3a9f6cb2223ca61cd3965bf55ee.Répondre à une livraison
Agentova considère une livraison comme réussie quand votre route répond par un statut 2xx en moins de 10 secondes — l’échange complet, pas seulement le premier octet. Le corps de votre réponse est ignoré. Tout le reste est une tentative échouée : un autre statut, un délai dépassé, une erreur de connexion — et aussi tout 3xx : les redirections ne sont jamais suivies, abonnez donc l’URL finale. Deux réponses ont un sens particulier :Nouveaux essais
Une livraison échouée est retentée, pour 8 tentatives au total sur environ 27 heures et demie :
Chaque tentative porte le même
id d’événement, avec une nouvelle signature (un nouveau t). Après la 8ᵉ tentative échouée, la livraison est abandonnée. Un Retry-After peut repousser une tentative au-delà de ce calendrier, mais aucune tentative n’est jamais programmée plus de 36 heures après la création de l’événement : quand la suivante le serait, la livraison est abandonnée.
Quand un abonnement est désactivé
Quand une livraison est abandonnée, Agentova désactive l’abonnement si les deux conditions sont réunies :- l’abonnement compte au moins 3 livraisons abandonnées d’affilée ;
- il échoue sans interruption depuis au moins 72 heures.
disabled_at est renseigné dans GET /webhooks, et les administrateurs de l’espace de travail sont prévenus dans l’application Agentova et par une notification push.
Un abonnement désactivé ne peut pas être réactivé : supprimez-le et créez-en un nouveau. Avec les connecteurs officiels, cela revient à désactiver puis réactiver le Zap (Zapier), ou à désactiver puis réactiver le workflow (n8n). Un abonnement désactivé est supprimé automatiquement 30 jours après sa désactivation.
Pendant que l’API est coupée
Agentova peut couper l’API temporairement : chaque appel reçoit alors503 service_unavailable. Pendant une telle coupure :
- aucune livraison n’est créée pour les événements qui surviennent entre-temps — ils ne seront jamais envoyés ;
- les livraisons déjà en cours sont suspendues, et reprennent quand l’API revient.
GET /leads, GET /runs et GET /automations.
Traiter une livraison
- Vérifiez la signature (voir plus haut), sur le corps brut, avant de l’analyser.
- Répondez
2xxen moins de 10 secondes, et faites le travail lourd ensuite — dans une file d’attente ou une tâche de fond. - Dédoublonnez sur
id: gardez les identifiants déjà traités pendant au moins 48 heures (les nouveaux essais sont toujours programmés dans les 36 heures qui suivent la création de l’événement), et répondez2xxà un doublon sans le traiter de nouveau. - Ne vous fiez pas à l’ordre d’arrivée : comparez
updated_at(automatisation),created_at(lead) ouoccurred_at(exécution).