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.
Créez les destinataires avec un ordre explicite
order à chaque destinataire. Les numéros les plus bas signent en premier.Envoyez la demande
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.Seul le premier signataire reçoit un email
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.signing_request.recipient.signed si vous voulez suivre chaque étape, et à signing_request.completed pour savoir quand toute la chaîne se termine.
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. La solution consiste à enchaîner deux demandes de signature plutôt que d’en modifier une :Envoyez la demande n° 1 avec uniquement le signataire 1
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.Attendez que le signataire 1 ait terminé
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.Lisez le champ rempli par le signataire 1
GET /signing-requests/{id}/fields et lisez final_value sur le champ dont le variable_name correspond.Créez et envoyez la demande n° 2 pour le signataire 2
id.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.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.Créez et envoyez la demande n° 1 pour le signataire 1
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.Intégrez la vue de signature du signataire 1
firma:signing:completed.À la fin, lisez l'email du signataire 2 depuis le champ
GET /signing-requests/{id}/fields et lisez final_value sur le champ dont le variable_name est "next_signer_email".Créez la demande n° 2 avec identity_editable_fields
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.Intégrez la vue de signature du signataire 2
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éfinissezsettings.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.
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 estSigner, 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.
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.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 :
POST /signing-requests/{id}/resend— renvoie l’email de notification aux destinataires actuellement au niveau de signature actif qui n’ont pas encore terminé. Cela ne vous permet pas de modifier leur email ni aucune autre donnée du destinataire.POST /signing-requests/{id}/cancel— arrête toute la demande pour tout le monde.
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
- Envoi d’une demande de signature — le flux de base de création/envoi sur lequel s’appuient ces scénarios
- Webhooks — types d’événements, vérification de signature et comportement de réessai
- Préremplissage des champs — remplissez les champs avec des données connues au lieu de demander au signataire de les compléter