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ééesigning_request.sent- Demande de signature envoyée aux destinatairessigning_request.viewed- Le destinataire a consulté le documentsigning_request.completed- Tous les destinataires ont terminé de signersigning_request.expired- La demande de signature a expirésigning_request.cancelled- La demande de signature a été annuléesigning_request.updated- Métadonnées de la demande de signature mises à joursigning_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 signaturesigning_request.recipient.declined- Le destinataire a refusé de signersigning_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èsdomain.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.
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)
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 actuelX-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 signaturev1= Empreinte hexadécimale HMAC-SHA256- Format de la charge utile signée :
{timestamp}.{json_body}
Obtenir votre secret de signature
- Accédez à votre tableau de bord Firma
- Consultez les détails du webhook pour récupérer le secret de signature
- 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 :- Firma génère un nouveau secret
- Pendant 7 jours, Firma envoie les deux signatures :
X-Firma-Signature(nouveau secret)X-Firma-Signature-Old(secret précédent)
- Après 7 jours, seule
X-Firma-Signatureest envoyée
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é
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 :consecutive_failures- Nombre d’échecs de livraison consécutifslast_failure_at- Horodatage de l’échec le plus récentenabled- 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}/testcontourne l’interrupteur maître, il peut donc réussir alors que les événements réels ne se déclenchent pas. - Vérifiez
consecutive_failuressur le webhook - s’il affiche0et 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.
- 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
- 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
- Mettez en œuvre l’idempotence en utilisant l’
idde l’événement - Stockez les identifiants d’événements traités dans votre base de données
- Vérifiez
consecutive_failureset 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-SignatureetX-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’
idde 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_failuresvia 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
- Créer un webhook via l’API
- Tester votre webhook avant la mise en production
- Mettre à jour les paramètres du webhook selon les besoins