Aller au contenu principal
Quelle Signature

API et intégrations

Webhooks de signature : recevez les notifications de l’éditeur et revérifiez chaque jour les demandes encore ouvertes

Pour qui : Développeur de PME qui doit savoir quand un contrat est signé, sans interroger l’API en boucle ni manquer un événement pendant une panne.

Ne fondez pas votre suivi sur la seule interrogation de l’API, où votre système demande lui-même où en est chaque signature. Recevez les webhooks, les notifications automatiques que l’éditeur envoie à votre système, vérifiez leur origine, placez-les en file d’attente, éliminez les doublons, et relisez chaque jour l’état des demandes encore ouvertes. La relance documentée, c’est-à-dire le temps pendant lequel l’éditeur renvoie une notification non reçue, va d’environ 1 h 20 chez Certyneo à un peu plus de quatre jours chez Youtrust : une panne de votre point d’entrée, l’adresse qui reçoit ces notifications, peut donc faire perdre un événement. Avant d’acheter, coupez votre point d’entrée et envoyez un faux appel sans la signature technique qui prouve son origine : c’est le test qui compte.

Notre avis

Le webhook déclenche la suite ; relire l’état de la demande rattrape ce qui a été manqué. Vous avez besoin des deux dès qu’un système dépend de la signature.

Pourquoi

  • Une panne de week-end sort de la fenêtre de relance de Certyneo, mais pas de celle de Youtrust.
  • La documentation de Signaturit lue ne décrit pas de signature technique des notifications, celle qui prouve leur origine : la notification reçue ne suffit alors pas à conclure.
  • Chez Certyneo, l’événement recipient.signed (un destinataire a signé) précède la disponibilité du PDF : un événement peut être vrai sans que le document soit prêt.

Ce qui change le choix

Pour quelques actes par mois sans automatisme, une relecture quotidienne suffit et vous épargne un point d’entrée à maintenir.

L’ordre à suivre

  1. Webhook dont l’origine est vérifiée, mis en file d’attente, sans doublon
  2. Relecture périodique des demandes encore ouvertes
  3. Interrogation seule, pour un très faible volume

Authentification et relance : ce que dit chaque documentation

La case « webhooks » d’une grille ne vous apprend rien sur deux points : l’authentification, qui permet de vérifier que l’appel vient bien de l’éditeur (la « signature » des appels est ici technique, sans rapport avec celle du contrat), et la relance, le temps pendant lequel l’éditeur renvoie une notification non reçue. Lisez-les pour l’éditeur que vous envisagez, et demandez ce que la documentation lue ne donne pas.

Selon les pages lues le 4 novembre 2026. « Non trouvé » vaut pour ces pages seulement.
ÉditeurAuthentification de l’appelRelance et durée
Docusign (extrait de recherche)HMAC-SHA256, en-têtes x-docusign-signature-1, -2, etc. ; TLS mutuel documenté à partPolitique de relance non lue
Youtrust, ex-YousignHMAC-SHA256 du corps brut, en-tête x-yousign-signature-256Jusqu’à 8 relances avec auto_retry, de 2 min à 2 jours ; cumul calculé : 96 h 38
UniversignJWS détaché PS256, en-tête x-jws-signature, clés publiques JWKS7 relances, de 1 min à 48 h, puis état failed ; cumul : 48 h ou 80 h 36, la page ne précisant pas le point de départ
CertyneoHMAC-SHA256 hexadécimal du corps brut, en-tête X-Certyneo-Signature5 tentatives sur environ 1 h 20, puis file rejouable
SignaturitAucune signature des appels décrite ; IP d’origine 34.241.96.22 indiquée pour le filtrage/v3/event-hooks avec relance, durée non trouvée
Namirial (FAQ en extrait)Signature des appels non lue30 appels de relance selon l’extrait
Goodflag (index seul)Signature des webhooks non lueNon lue. Webhooks hors du pack ponctuel selon un extrait de la page tarifs
Oodrive (page commerciale)Non lue« Unlimited webhooks » annoncés, relance non lue

Le calcul à refaire : votre panne la plus probable contre la fenêtre de relance

Chez Youtrust, les délais s’ajoutent après chaque tentative : 2 + 6 + 30 + 60 + 300 + 1 080 + 1 440 + 2 880 minutes font 5 798 minutes, soit 96 h 38. Universign liste 1, 5, 30, 120, 360, 1 440 et 2 880 minutes : si ce sont des intervalles, le total atteint 4 836 minutes, soit 80 h 36 ; si ce sont des décalages depuis le premier envoi, la relance s’arrête à 48 h.

Exemple fictif : votre serveur tombe le vendredi à 20 h et revient le lundi à 8 h, soit 60 heures. Sur la lecture la plus longue, Universign et Youtrust relancent encore ; sur la plus courte, Universign a fini à 48 h. Chez Certyneo, les 5 tentatives sont épuisées et il faudra rejouer la file. Dans les trois cas, une relecture d’état au retour vous évite de dépendre de cette réponse.

Youtrust ajoute un piège : un code 2xx (une réponse de succès) reçu après une seconde à la première tentative, et après dix secondes aux relances, compte comme un échec, et des échecs répétés peuvent suspendre temporairement l’envoi vers votre point d’entrée. Ne faites donc aucun traitement avant de répondre.

L’interrogation, elle, a ses bornes : Docusign la limite à une fois par 15 minutes, soit 96 lectures par jour au plus (24 × 4), selon les extraits lus, dont le périmètre exact reste à vérifier.

Les six tests à passer avant la mise en service

  1. Appel falsifié. Envoyez un appel au contenu modifié ou sans signature technique : il doit être rejeté, sans aucune écriture dans votre base. Là où aucune signature technique n’est documentée, le filtrage par adresse IP ne suffit pas : rechargez l’état de la demande par l’API avant d’agir sur un appel reçu.
  2. Doublon. Renvoyez le même événement deux fois : il ne doit produire qu’une seule action dans votre système. Youtrust recommande de dédoublonner par event_id, Certyneo par X-Certyneo-Delivery-Id.
  3. Ordre inversé. Faites arriver la fin de demande avant la signature d’un participant : l’état final ne recule pas.
  4. Lenteur. Ajoutez deux secondes de traitement avant la réponse : vous voyez le faux échec. Corrigez en répondant tout de suite puis en traitant en file.
  5. Panne. Coupez le point d’entrée pendant une durée plus longue que la relance : la relecture d’état ou le rejeu retrouve tous les événements.
  6. Document pas encore prêt. Chez Certyneo, attendez l’événement envelope.completed (la demande de signature est terminée) pour récupérer le PDF, l’événement recipient.signed (un destinataire a signé) arrivant avant. Vérifiez l’équivalent chez votre éditeur.

Recevoir, vérifier, mettre en file d’attente, répondre, puis relire l’état chaque jour

Le point d’entrée fait quatre choses, dans l’ordre : vérifier la signature technique sur le contenu brut de l’appel, écrire l’événement avec son identifiant, répondre, laisser un traitement séparé agir. Une tâche quotidienne relit ensuite les demandes ouvertes depuis plus d’un jour et corrige les écarts. Elle signale aussi toute correction : une correction fréquente veut dire que les webhooks ne font pas leur travail.

Sur Certyneo, les plans Free et Personal limitent les événements au bac à sable. Vérifiez ce point avant de choisir votre plan.

Limites de cette page

Aucun webhook n’a été reçu par nos soins. Docusign et la FAQ de Namirial sont lus par extraits de recherche, Goodflag par son index, Oodrive sur une page commerciale. La page de Certyneo annonce 11 événements et en liste 12. Une absence dans ce tableau signifie seulement que nous ne l’avons pas trouvée dans la documentation lue.

Prochaine action

Demandez à votre éditeur, par écrit, la méthode d’authentification de ses appels et la durée totale de relance, puis jouez le test de panne sur votre environnement de préproduction.

Preuves et sources

Documentations de Youtrust, Universign, Signaturit et Certyneo, index de Goodflag, extraits de recherche pour Docusign et pour la FAQ de Namirial, page commerciale d’Oodrive, lus le 4 novembre 2026. Aucun webhook n’a été reçu par nos soins.

Chaque élément ci-dessous indique s’il s’agit d’un fait lu dans une source, d’une déclaration de son auteur, de notre calcul, de notre méthode ou de notre avis. Vérifiez sur le document toute source marquée à vérifier ou non tranchée avant de vous y fier. Notre méthode

  • Déclaration de l’émetteur. Selon des extraits de sa documentation, Docusign Connect signe ses appels en HMAC-SHA256 avec les en-têtes x-docusign-signature-1, -2 et suivants, et documente le TLS mutuel à part.

    Périmètre : Docusign Connect

    Réserve : Extrait de recherche ; politique de relance non lue.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Youtrust signe ses webhooks en HMAC-SHA256 du corps brut, comparé à x-yousign-signature-256, et relance jusqu’à 8 fois avec auto_retry aux délais de 2 min, 6 min, 30 min, 1 h, 5 h, 18 h, 1 jour et 2 jours.

    Périmètre : Youtrust, ex-Yousign

    Réserve : Sans auto_retry, une relance unique si le premier échec est un délai dépassé.

    Relevé du 4 novembre 2026.

  • Notre calcul ou déduction. Les délais de relance de Youtrust totalisent 5 798 minutes, soit 96 h 38.

    Périmètre : Calcul à partir des délais publiés

    Réserve : La page ne donne pas de total.

    Relevé du 4 novembre 2026.

  • Notre calcul ou déduction. Universign signe ses webhooks en JWS détaché PS256 et relance après 1 min, 5 min, 30 min, 2 h, 6 h, 24 h et 48 h, puis passe l’état à failed ; le cumul est de 48 h ou de 80 h 36, la page ne précisant pas s’il s’agit de décalages ou d’intervalles.

    Périmètre : Universign

    Réserve : Lecture du point de départ à faire confirmer.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Certyneo signe ses webhooks en HMAC-SHA256 hexadécimal du corps brut, avec 5 tentatives sur environ 1 h 20 et une file rejouable, dédoublonnage par X-Certyneo-Delivery-Id, et recipient.signed précède la disponibilité du PDF.

    Périmètre : Certyneo

    Réserve : La page annonce 11 événements et en liste 12.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. La documentation de Signaturit décrit des abonnements et /v3/event-hooks avec relance, et indique l’IP 34.241.96.22 pour le filtrage, sans décrire de signature des appels.

    Périmètre : API Signaturit

    Réserve : Constat sur le texte lu, pas une preuve d’absence.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Selon un extrait de la FAQ de Namirial, le callback connaît 30 appels de relance ; la signature des appels n’a pas été lue.

    Périmètre : eSignAnyWhere

    Réserve : Hôte de la FAQ injoignable en lecture directe.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. L’index de documentation de Goodflag liste des webhooks globaux et utilisateur ; un extrait de sa page tarifs les exclut du pack ponctuel ; signature et relance n’ont pas été lues.

    Périmètre : Goodflag, nom commercial de Lex Persona

    Réserve : Index lu, pas les pages ; la page tarifs comporte par ailleurs une divergence de prix.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Oodrive annonce des webhooks illimités sur une page commerciale, sans préciser relance ni signature des appels.

    Périmètre : Oodrive Sign

    Réserve : Page commerciale.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Youtrust compte comme échec une réponse valide reçue après 1 seconde à la première tentative ou après 10 secondes aux relances, et peut suspendre temporairement les envois après des échecs répétés.

    Périmètre : Youtrust

    Réserve : Non testé.

    Relevé du 4 novembre 2026.

  • Notre calcul ou déduction. Selon des extraits de sa documentation, Docusign limite l’interrogation d’état à une fois par 15 minutes, soit au plus 96 lectures par jour.

    Périmètre : Docusign

    Réserve : Extraits de recherche ; calcul 24 × 4 ; périmètre exact de la règle non lu.

    Relevé du 4 novembre 2026.

  • Déclaration de l’émetteur. Sur les plans Free et Personal de Certyneo, les événements sont limités au bac à sable.

    Périmètre : Certyneo

    Réserve : Source : connecteur rédigé par l’éditeur.

    Relevé du 4 novembre 2026.

  • Notre avis. Le webhook doit déclencher et la relecture d’état réconcilier, dès qu’un système dépend de la signature.

    Périmètre : Intégrations de PME

    Réserve : Avis d’architecture, sans mesure de terrain.

    Daté du 4 novembre 2026.

  • Notre méthode. Les six tests et la chaîne de réception forment la méthode proposée ; la panne de 60 heures est un exemple fictif.

    Périmètre : À exécuter par le lecteur

    Réserve : Non testé chez ces éditeurs.

    Daté du 4 novembre 2026.