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.certificate.generated- Certificat de signature générésigning_request.reminder.sent- Rappel envoyé aux destinatairessigning_request.field.filled- Un champ a été rempli par un destinatairesigning_request.document.updated- Le document a été mis à jour
Événements de destinataire
signing_request.recipient.added- Destinataire ajouté à la demande de signaturesigning_request.recipient.signed- Le destinataire a terminé la signaturesigning_request.recipient.declined- Le destinataire a refusé de signersigning_request.recipient.updated- Détails du destinataire mis à joursigning_request.recipient.identity_changed- Le destinataire a changé son identité (nom, société, etc.) pendant la signature
Événements de modèle
template.created- Nouveau modèle créétemplate.updated- Modèle modifiétemplate.deleted- Modèle supprimétemplate.field.added- Champ ajouté au modèletemplate.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éworkspace.deleted- Espace de travail supprimé
Événements de domaine
domain.verified- Domaine vérifié avec succèsdomain.verification.failed- Échec de la vérification du domaine
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. Firma enverra un événement de test lors de la création pour vérifier le point de terminaison.
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 24 heures)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 24 heures, Firma envoie les deux signatures :
X-Firma-Signature(nouveau secret)X-Firma-Signature-Old(secret précédent)
- Après 24 heures, 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 : 1 minute, 5 minutes, 30 minutes, 2 heures, 6 heures
- Nombre total de tentatives : Jusqu’à 5 nouvelles 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 : Les requêtes GET de webhook prennent en charge 60 requêtes par minute par clé API.
Dépannage
Problèmes courants
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
- 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