Événements webhook¶
Le mécanisme de livraison et les payloads sont identiques pour les deux flux d'intégration (voidsign_mail et caller_embed). Une seule différence : l'événement request.invite_sent n'est émis qu'en flux voidsign_mail, car il correspond à l'e-mail d'invitation, qui n'est pas envoyé en caller_embed. Les relances (request.manual_reminder_sent, request.programmed_reminder_sent) peuvent en revanche survenir dans les deux flux si reminder_days est renseigné. En flux embarqué, votre page parente reçoit en plus un événement postMessage voidsign:signed par signataire ; il n'est pas livré côté serveur. Voir Intégrer la signature sur votre application.
Types d'événements¶
| Événement | Description |
|---|---|
request.invite_sent |
L'e-mail d'invitation a été envoyé à un signataire |
request.manual_reminder_sent |
Un e-mail de relance déclenché par un utilisateur depuis la plateforme a été envoyé à un signataire |
request.programmed_reminder_sent |
Un e-mail de relance programmé (planifié) a été envoyé à un signataire |
request.partial_signed |
Un des signataires a signé, cependant la demande n'est pas encore complète |
request.completed |
Tous les signataires ont signé la demande |
request.cancelled |
La demande a été annulée / révoquée |
hello |
Événement de test envoyé lorsque vous vérifiez votre endpoint lors de la configuration/débogage (toujours livré à la demande manuelle) |
D'autres types d'événements seront ajoutés à l'avenir. Vous pouvez configurer le webhook pour recevoir tous les types d'événements (actuels et futurs).
Pour les instructions de configuration et la vérification des signatures, consultez Configurer les webhooks.
En-têtes HTTP¶
VoidSign livre les webhooks sous forme de requêtes POST avec les en-têtes suivants :
| En-tête | Description |
|---|---|
Content-Type |
application/json |
User-Agent |
VoidSign-Webhook/1.0 |
webhook-id |
Identifiant unique de livraison (msg_<uuid>) |
webhook-timestamp |
Horodatage Unix (secondes) de l'envoi de l'événement |
webhook-signature |
Signature HMAC-SHA256 (v1,<base64>) |
Exemple de requête HTTP brute :
POST /webhooks/voidsign HTTP/1.1
Host: example.com
Content-Type: application/json
User-Agent: VoidSign-Webhook/1.0
webhook-id: msg_a1b2c3d4-e5f6-7890-abcd-ef1234567890
webhook-timestamp: 1742140948
webhook-signature: v1,U2lnbmF0dXJlIG9mIGEgdm9pZHNpZ24gbWVzc2FnZQ==
{"data":{"request_id":"a1b2c3d4-e5f6-7890-abcd-ef1234567890"},"timestamp":"2026-03-16T17:42:28+00:00","type":"request.completed"}
Schémas de payload¶
Chaque payload est un objet JSON comportant un type (le nom de l'événement) et un timestamp (ISO 8601, le moment où l'événement s'est produit). Tous les événements sauf hello comportent également un objet data. Il n'existe que trois formes de data :
Forme de data |
Événements |
|---|---|
request_id + signer_id |
request.invite_sent, request.manual_reminder_sent, request.programmed_reminder_sent, request.partial_signed |
request_id uniquement |
request.completed, request.cancelled |
aucun champ data |
hello |
Un exemple par forme (tout autre événement du même groupe est identique, à l'exception de son type) :
request_id + signer_id :
{
"type": "request.invite_sent",
"timestamp": "2026-03-16T17:42:28+00:00",
"data": {
"request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"signer_id": "11111111-2222-3333-4444-555555555555"
}
}
request_id uniquement :
{
"type": "request.completed",
"timestamp": "2026-03-16T17:42:28+00:00",
"data": {
"request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}
}
aucun champ data :
Propriétés du payload¶
- La valeur du
webhook-idest unique pour chaque événement VoidSign, ceci vous permet d'assurer l'idempotence au sein de votre propre système pour gérer les payloads rejoués. - La valeur de l'en-tête
webhook-timestampest l'horodatage utilisé pour la signature mais pas l'horodatage de l'événement. Consultez l'avertissement ci-dessous. - La valeur de l'en-tête
webhook-signatureest la signature attendue de la requête. Consultez Vérifier les signatures. - Le type d'événement est toujours fourni dans le corps de la requête au chemin JSON
.type. - L'horodatage de l'événement est toujours fourni dans le corps de la requête au chemin JSON
.timestamp. - Les données de l'événement sont toujours fournies dans le corps de la requête au chemin JSON
.data. Les schémas spécifiques dépendent du type d'événement.
Horodatage des données vs horodatage du webhook
- L'horodatage des données, c'est-à-dire l'horodatage présent dans le corps de la requête, représente le moment où l'événement s'est produit (par exemple, quand le dernier signataire a signé).
- L'horodatage du webhook, c'est-à-dire la valeur de l'en-tête
webhook-timestamp, correspond au moment où la livraison a été tentée par les serveurs VoidSign.
Comportement de réessai¶
Si votre endpoint ne retourne pas une réponse 2xx, VoidSign retente la livraison avec un backoff exponentiel sur de courtes durées, puis un backoff linéaire sur de plus longues durées. Les livraisons qui ne peuvent pas être complétées sont finalement abandonnées.
Votre endpoint doit être idempotent : utilisez l'en-tête webhook-id pour détecter les livraisons en double et éviter de traiter le même événement deux fois.
Calendrier de réessai
Le calendrier exact de réessai pourra être mis à jour à l'avenir pour s'aligner sur la spécification de réessai Standard Webhooks.