Skip to main content
Ce guide couvre les schémas récurrents que prennent les flux de signature : plusieurs signataires qui signent dans l’ordre, des signataires qui n’ont pas besoin d’ordre, un deuxième signataire dont l’identité n’est connue qu’après que le premier a agi, et un signataire qui doit aussi approuver. Chaque scénario ci-dessous est une variation de la création et de l’envoi d’une demande de signature, lisez donc d’abord ce guide si ce n’est pas déjà fait.

Choisir un scénario

Scénario : Signature séquentielle, destinataires connus

Utilisez ce scénario lorsque l’email de chaque destinataire est connu au moment de l’envoi et que les signataires suivants ne doivent être notifiés qu’une fois les précédents terminés. C’est le comportement par défaut : settings.use_signing_order vaut 1 sauf si vous le désactivez, et les destinataires signent dans l’ordre croissant de order.
1

Créez les destinataires avec un ordre explicite

Attribuez un order à chaque destinataire. Les numéros les plus bas signent en premier.
2

Envoyez la demande

Utilisez create-and-send pour un seul appel, ou create suivi de /send si vous avez besoin d’une étape de révision au préalable.
3

Seul le premier signataire reçoit un email

Firma envoie immédiatement un email aux destinataires avec order: 1. Une fois qu’ils ont terminé, Firma envoie automatiquement l’email au niveau order suivant — vous ne pilotez pas cela vous-même. Abonnez-vous aux webhooks plutôt que d’effectuer un sondage si vous voulez suivre chaque étape.
Bob ne reçoit aucun email tant qu’Alice n’a pas complété ses champs. Abonnez-vous à signing_request.recipient.signed si vous voulez suivre chaque étape, et à signing_request.completed pour savoir quand toute la chaîne se termine.
Les valeurs d’order doivent simplement se trier correctement — elles n’ont pas besoin d’être contiguës. Cependant, les valeurs d’order identiques (p. ex. 1, 2, 2, 5) ne créent pas un niveau de signature parallèle — un seul destinataire par valeur d’order est notifié à la fois. Si vous avez besoin que deux signataires signent simultanément, utilisez le schéma parallèle avec use_signing_order: false à la place.

Scénario : Deuxième signataire dynamique

C’est le cas à l’origine de la plupart des tickets du type « comment ajouter un signataire en cours de flux » : le signataire 1 renseigne quelque chose — une recommandation, un cosignataire, un bénéficiaire — et ce n’est qu’à ce moment-là que vous connaissez l’email du signataire 2. Le réflexe est d’envoyer la demande avec uniquement le signataire 1, puis de la mettre à jour pour ajouter le signataire 2 une fois que vous savez qui il est.
Cette mise à jour n’est pas possible sur la même demande de signature. Une fois que sent_on est défini, PATCH/PUT /signing-requests/{id} et DELETE /signing-requests/{id} renvoient tous 409 ALREADY_SENT — une demande de signature envoyée est totalement immuable, y compris pour l’ajout d’un nouveau destinataire. Il n’existe aucun endpoint permettant d’ajouter un destinataire à une demande déjà envoyée, ni de modifier l’email d’un destinataire sur celle-ci. Consultez Gestion des erreurs : 409 ALREADY_SENT ci-dessous pour la liste complète des opérations que cela bloque.
La solution consiste à enchaîner deux demandes de signature plutôt que d’en modifier une :
1

Envoyez la demande n° 1 avec uniquement le signataire 1

Incluez un champ (type: "text", avec un variable_name du type next_signer_email) pour que le signataire 1 indique le signataire suivant. Envoyez-la avec create-and-send, avec exactement un destinataire.
2

Attendez que le signataire 1 ait terminé

Comme la demande n° 1 n’a qu’un seul signataire, signing_request.completed se déclenche dès qu’il a terminé — vous n’avez pas besoin de signing_request.recipient.signed dans ce cas.
3

Lisez le champ rempli par le signataire 1

Le payload du webhook ne contient pas les valeurs des champs, appelez donc GET /signing-requests/{id}/fields et lisez final_value sur le champ dont le variable_name correspond.
4

Créez et envoyez la demande n° 2 pour le signataire 2

Utilisez l’email que vous venez d’extraire. Il s’agit d’une nouvelle demande de signature, avec son propre id.
Comme il s’agit de deux demandes de signature distinctes, cela produit deux certificats d’achèvement et deux pistes d’audit distincts — il n’existe pas de certificat unique couvrant les deux signataires. Si un certificat unifié est une exigence incontournable, la seule alternative consiste à recueillir l’email du signataire 2 avant l’envoi — par exemple via un formulaire dans votre propre application — plutôt qu’en cours de flux.
Firma n’a pas de champ de métadonnées ou de référence externe sur la demande de signature elle-même pour relier la demande n° 1 et la demande n° 2. Stockez cette correspondance (par exemple original_signing_request_id) dans votre propre base de données lorsque vous créez la demande n° 2.

Approche 1 : Deuxième demande déclenchée par webhook

Utilisez ce scénario lorsque les signataires reçoivent des invitations par email et que votre backend gère la chaîne.
Répondez 200 avant d’effectuer la recherche du champ et l’appel de création et d’envoi qui suit — la livraison des webhooks de Firma expire au bout de 5 secondes, et le scénario ci-dessus implique lui-même deux appels API sortants.

Approche 2 : Signature intégrée avec champs d’identité modifiables

Utilisez ce scénario lorsque vous intégrez la signature directement dans votre application et que vous souhaitez que le signataire 2 confirme ou corrige sa propre identité à l’ouverture de la vue de signature — sans flux basé sur l’email.
1

Créez et envoyez la demande n° 1 pour le signataire 1

Incluez un champ de texte (p. ex. variable_name: "next_signer_email") pour que le signataire 1 indique l’email du signataire 2. Définissez send_signing_email: false puisque vous intégrez vous-même la vue de signature.
2

Intégrez la vue de signature du signataire 1

Utilisez le composant de signature intégrable pour afficher la vue de signature du signataire 1 dans votre application. Écoutez l’événement postMessage firma:signing:completed.
3

À la fin, lisez l'email du signataire 2 depuis le champ

Appelez GET /signing-requests/{id}/fields et lisez final_value sur le champ dont le variable_name est "next_signer_email".
4

Créez la demande n° 2 avec identity_editable_fields

Créez une nouvelle demande de signature pour le signataire 2 avec settings.identity_editable_fields défini sur ["first_name", "last_name", "email"]. Cela permet au signataire 2 de vérifier et de corriger sa propre identité à l’ouverture de la vue de signature — utile lorsque le signataire 1 a pu fournir des informations approximatives.
5

Intégrez la vue de signature du signataire 2

Affichez la vue de signature du signataire 2 dans votre application. Le signataire 2 voit son identité pré-remplie, peut la corriger si nécessaire, puis signe.
Définir identity_editable_fields: ["first_name", "last_name", "email"] permet au signataire 2 de mettre à jour son propre nom et email dans la vue de signature avant de signer. Si le signataire 1 a fourni un nom approximatif, le signataire 2 le corrige lui-même. Définissez notify_identity_change_email: 1 pour recevoir une notification lorsqu’un signataire modifie son identité.

Scénario : Signature en parallèle

Utilisez ce scénario lorsque les signataires sont indépendants les uns des autres — personne n’a besoin d’attendre qu’un autre termine. Définissez settings.use_signing_order: false sur la demande. Une fois désactivée, Firma envoie un email à tous les destinataires au moment de l’envoi, au lieu de conditionner les niveaux suivants à l’achèvement des précédents. Les valeurs d’order restent stockées sur chaque destinataire, mais elles ne sont pas appliquées — personne n’est bloqué pour avoir signé hors de son tour.
Les trois reçoivent immédiatement leur email de signature. La demande se termine (et signing_request.completed se déclenche) une fois qu’ils ont tous terminé, quel que soit l’ordre dans lequel ils signent réellement.

Scénario : Signataire et approbateur

Le modèle de désignation de Firma est délibérément exclusif : une ligne de destinataire est Signer, Approver ou CC — jamais plus d’une. Si la même personne doit à la fois signer puis approuver, elle apparaît sous deux lignes avec des valeurs d’order différentes, et non une ligne avec deux rôles.
Les champs comptent aussi ici : les champs approval_signature, approval_checkmark et approval_date ne peuvent être attribués qu’à un destinataire dont la designation est Approver — en attribuer un à une ligne Signer renvoie une erreur 400. Leur valeur est générée côté serveur lorsque l’approbateur termine sa révision ; vous ne la soumettez pas vous-même.
Cela se combine également avec la signature séquentielle : donnez à la ligne Signer un order inférieur à celui de la ligne Approver, et l’étape d’approbation d’Alice elle-même ne se débloquera qu’une fois qu’elle aura fini de signer.

Gestion des erreurs : 409 ALREADY_SENT

ALREADY_SENT signifie que la demande de signature possède un horodatage sent_on et que l’opération que vous avez tentée ne fonctionne que sur un brouillon. Elle est renvoyée, avec le code 409, par : Ce que vous pouvez encore faire sur une demande envoyée mais non finalisée : Si vous rencontrez ALREADY_SENT en essayant de corriger une faute de frappe dans l’email d’un destinataire ou d’ajouter un destinataire que vous avez oublié, il n’existe aucune correction sur place — annulez et recréez, ou (pour le cas « le deuxième destinataire n’était pas encore connu ») utilisez le scénario du deuxième signataire dynamique décrit plus haut.

Prochaines étapes