Skip to main content
Firma envoie des événements webhook pour notifier votre application des changements du cycle de vie de signature, des finalisations de documents et des activités de l’espace de travail. Les webhooks permettent des intégrations en temps réel sans polling.

Cas d’usage courants

  • Envoyer des notifications internes lorsque des documents sont signés
  • Mettre à jour votre base de données lorsque des demandes de signature sont terminées
  • Déclencher des workflows en aval (facturation, provisionnement, etc.)
  • Suivre les changements de statut des demandes de signature en temps réel

Types d’événements

Firma envoie les types d’événements suivants :

Événements de demande de signature

  • signing_request.created - Nouvelle demande de signature créée
  • signing_request.sent - Demande de signature envoyée aux destinataires
  • signing_request.viewed - Le destinataire a consulté le document
  • signing_request.completed - Tous les destinataires ont terminé de signer
  • signing_request.expired - La demande de signature a expiré
  • signing_request.cancelled - La demande de signature a été annulée
  • signing_request.updated - Métadonnées de la demande de signature mises à jour
  • signing_request.deleted - Demande de signature supprimée (avant l’envoi)
  • signing_request.certificate.generated - Certificat de signature généré
  • signing_request.reminder.sent - Rappel envoyé aux destinataires

Événements de destinataire

  • signing_request.recipient.signed - Le destinataire a terminé la signature
  • signing_request.recipient.declined - Le destinataire a refusé de signer
  • signing_request.recipient.identity_changed - Le destinataire a changé son identité (nom, société, etc.) pendant la signature

Événements de modèle

  • template.updated - Modèle modifié
  • template.used - Modèle utilisé pour créer une demande de signature

Événements d’espace de travail

  • workspace.created - Nouvel espace de travail créé
  • workspace.updated - Espace de travail modifié

Événements de domaine

  • domain.verified - Domaine vérifié avec succès
  • domain.verification.failed - Échec de la vérification du domaine

Deux niveaux d’activation

La livraison des webhooks nécessite que les deux interrupteurs soient activés : un interrupteur par webhook et un interrupteur maître au niveau du compte. Les deux sont indépendants, si bien qu’un webhook peut être créé et activé correctement sans jamais déclencher le moindre événement. Au moins une portée (entreprise ou espace de travail) doit avoir son interrupteur maître activé pour que tout webhook de cette portée soit livré. Activer l’interrupteur maître de l’espace de travail génère également un secret de signature pour cet espace de travail s’il n’en existe pas déjà un.
POST /webhooks/{id}/test contourne l’interrupteur maître. Une livraison de test peut réussir même si l’interrupteur maître est désactivé et que les événements réels ne sont pas livrés - un test réussi ne confirme pas que les événements réels se déclencheront.
Lorsque l’interrupteur maître est désactivé, Firma ignore l’événement avant même d’enregistrer une tentative de livraison. consecutive_failures reste à 0 et le webhook n’affiche aucun historique d’échec, alors même que rien n’est livré - il n’y a aucune erreur pour vous alerter.

Autorisations

Activer ou désactiver l’interrupteur maître au niveau de l’entreprise nécessite un accès propriétaire ou administrateur de l’entreprise ; les membres en lecture seule ne peuvent ni l’activer ni le désactiver. Toute tentative de le faire sans autorisations suffisantes renvoie une erreur de permission.

Créer un webhook

Créez des webhooks via l’API ou le tableau de bord :
Votre URL de webhook doit utiliser HTTPS et répondre en moins de 5 secondes. Utilisez POST /webhooks/{id}/test après la création pour vérifier que votre point de terminaison reçoit correctement les événements.

Structure de la charge utile du webhook

Tous les événements webhook suivent cette structure standard :

Sécurité : vérification de la signature (obligatoire)

Vérifiez toujours les signatures des webhooks pour éviter les attaques par usurpation. Ne traitez pas les webhooks sans vérification de signature.
Firma signe toutes les requêtes webhook avec HMAC SHA-256. Votre point de terminaison de webhook reçoit ces en-têtes :
  • X-Firma-Signature - Signature HMAC utilisant le secret de signature actuel
  • X-Firma-Signature-Old - Signature HMAC utilisant le secret précédent (pendant la période de grâce de rotation de 7 jours)
  • X-Firma-Event - Type d’événement (par ex., signing_request.completed)
  • X-Firma-Delivery - Identifiant unique de tentative de livraison

Format de la signature

Firma utilise un en-tête de signature horodaté :
  • En-tête : X-Firma-Signature: t=1707500000,v1=abc123def456...
  • t = Horodatage Unix (secondes) au moment de la génération de la signature
  • v1 = Empreinte hexadécimale HMAC-SHA256
  • Format de la charge utile signée : {timestamp}.{json_body}
Exemple :

Obtenir votre secret de signature

  1. Accédez à votre tableau de bord Firma
  2. Consultez les détails du webhook pour récupérer le secret de signature
  3. Stockez le secret de manière sécurisée (variable d’environnement ou gestionnaire de secrets)

Exemple de vérification - Node.js (Express)

Exemple de vérification - Python (Flask)

Gestion de la rotation des secrets

Lorsque vous faites une rotation de votre secret de signature de webhook :
  1. Firma génère un nouveau secret
  2. Pendant 7 jours, Firma envoie les deux signatures :
  • X-Firma-Signature (nouveau secret)
  • X-Firma-Signature-Old (secret précédent)
  1. Après 7 jours, seule X-Firma-Signature est envoyée
Mise en œuvre : Vérifiez d’abord X-Firma-Signature. Si la vérification échoue et que X-Firma-Signature-Old existe, vérifiez avec l’ancien secret.

Comportement de nouvelle tentative

Firma réessaie automatiquement les livraisons de webhook échouées :
  • Calendrier des tentatives : Immédiat, puis +5 minutes, puis +1 heure
  • Nombre total de tentatives : Jusqu’à 3 tentatives par événement
  • Délai d’expiration : Votre point de terminaison doit répondre en moins de 5 secondes
  • Succès : Tout code de statut 2xx indique un succès
  • Désactivation automatique : Après 50 échecs consécutifs, le webhook est automatiquement désactivé
Bonne pratique : Répondez immédiatement avec 200, puis traitez les événements de manière asynchrone (file d’attente, tâche en arrière-plan, etc.) pour éviter les délais d’expiration.

Idempotence

Gérez toujours les événements dupliqués en utilisant l’id de l’événement :

Surveiller l’état de santé du webhook

Surveillez l’état de santé de votre webhook en consultant les détails du webhook :
La réponse inclut :
  • consecutive_failures - Nombre d’échecs de livraison consécutifs
  • last_failure_at - Horodatage de l’échec le plus récent
  • enabled - Indique si le webhook est actif (désactivé automatiquement après 50 échecs)
  • last_success_at - Horodatage de la livraison réussie la plus récente
Limite de débit : Toutes les opérations /webhooks (GET comme écriture) partagent une limite de 60 requêtes par minute par clé API. POST /webhooks/{id}/test dispose de sa propre limite distincte de 10 requêtes par minute.

Dépannage

Problèmes courants

Les webhooks sont configurés mais les événements ne se déclenchent pas C’est la cause la plus fréquente des signalements « mon webhook ne fonctionne pas ». La configuration par webhook peut être entièrement correcte alors que l’interrupteur maître au niveau du compte est désactivé, ce qui ignore silencieusement chaque événement.
  • Vérifiez que l’interrupteur maître est activé pour la bonne portée : les webhooks au niveau de l’entreprise nécessitent que l’interrupteur de l’entreprise soit activé, les webhooks au niveau de l’espace de travail nécessitent que l’interrupteur de cet espace de travail soit activé.
  • Ne considérez pas un test réussi comme une preuve - POST /webhooks/{id}/test contourne l’interrupteur maître, il peut donc réussir alors que les événements réels ne se déclenchent pas.
  • Vérifiez consecutive_failures sur le webhook - s’il affiche 0 et qu’aucun événement n’apparaît, cela pointe également vers l’interrupteur maître, puisque les événements ignorés ne sont jamais enregistrés comme des tentatives de livraison échouées.
  • Si vous ne trouvez pas ou ne pouvez pas basculer l’interrupteur maître, il se peut que vous n’ayez pas les autorisations de propriétaire ou d’administrateur sur l’entreprise ; demandez à un propriétaire ou un administrateur de l’activer depuis Paramètres > Webhooks.
401 Unauthorized / Signature invalide
  • Vérifiez que vous utilisez le bon secret de signature
  • Vérifiez que vous hachez le corps brut de la requête (et non le JSON parsé)
  • Assurez-vous d’utiliser HMAC SHA-256, et non un autre algorithme de hachage
Délais d’expiration / Erreurs 504
  • Répondez immédiatement avec 200, traitez de manière asynchrone
  • Vérifiez que votre point de terminaison répond en moins de 5 secondes
  • Utilisez des tâches/files d’attente en arrière-plan pour le traitement lourd
Événements dupliqués
  • Mettez en œuvre l’idempotence en utilisant l’id de l’événement
  • Stockez les identifiants d’événements traités dans votre base de données
Webhook désactivé automatiquement
  • Vérifiez consecutive_failures et les journaux d’événements récents
  • Corrigez les problèmes du point de terminaison, puis réactivez le webhook via l’API ou le tableau de bord

Tester les webhooks localement

Utilisez un service de tunnel comme ngrok pour le développement local :

Liste de contrôle pour la production

  • Vérifiez les signatures HMAC sur toutes les requêtes de webhook
  • Gérez la rotation des signatures (vérifiez à la fois X-Firma-Signature et X-Firma-Signature-Old)
  • Répondez avec 200 en moins de 5 secondes
  • Traitez les événements de manière asynchrone (files d’attente/tâches en arrière-plan)
  • Mettez en œuvre l’idempotence en utilisant l’id de l’événement
  • Stockez le secret de signature de manière sécurisée (variable d’environnement ou gestionnaire de secrets)
  • Surveillez la métrique consecutive_failures via le point de terminaison GET du webhook
  • Configurez des alertes pour les échecs de webhook
  • Enregistrez tous les événements webhook pour le débogage
  • Testez avec tous les types d’événements souscrits
  • Restez dans les limites de débit (voir le Guide des limites de débit)

Prochaines étapes