Skip to main content

​
Démarrage et compte

Oui. La clé principale de votre compte se trouve sur la page Tableau de bord de l’interface ; les clés propres à chaque espace de travail se trouvent dans l’onglet Infos de cet espace de travail, et il n’existe pas de page distincte « Settings > API Keys ». Vous pouvez également les récupérer via l’API. Seul le Propriétaire de l’espace de travail peut générer ou régénérer des clés depuis le tableau de bord.Voir : Authentification API et jetons JWT, Guide de configuration complet
Non, Firma.dev ne propose pas de période d’essai distincte ni de compte bac à sable, et le mode test ne coûte rien à utiliser. Les requêtes effectuées avec une clé test restent soumises aux limites de débit normales de l’API, comme les requêtes en mode live, et les éditeurs intégrables ainsi que la page de signature hébergée se comportent de manière identique en mode test et en mode live.Voir : Authentification API et jetons JWT, Guide de configuration complet
Non. L’inscription est en libre-service, sans contrat ni démo commerciale requise : créez un compte, acceptez les conditions générales d’utilisation standard lors de l’inscription, et récupérez votre clé API depuis le tableau de bord. La tarification ne comporte ni minimum, ni contrat, ni frais mensuels. Vous pouvez intégrer directement à partir de la documentation, du serveur MCP, ou de l’un des guides d’intégration d’outils de codage IA de Firma.dev (Claude Code, Cursor, ChatGPT, et d’autres) sans jamais avoir à contacter l’équipe commerciale.
Firma.dev propose trois rôles de compte : Propriétaire, Administrateur, et Lecture seule.
  • Propriétaire : seul rôle pouvant gérer la facturation, créer, supprimer ou renommer des espaces de travail, et générer ou régénérer des clés API.
  • Propriétaire et Administrateur : peuvent tous deux gérer les webhooks, les domaines personnalisés, les paramètres d’entreprise, les utilisateurs et les demandes de signature. Seul un Propriétaire peut modifier les paramètres stockés sur l’espace de travail, comme la vérification OTP, l’acceptation des conditions et le cadre de signature.
  • Lecture seule : peut uniquement lire et copier les données existantes.
Quelques paramètres à bascule au niveau de l’espace de travail, comme la vérification OTP ou l’affichage du cadre de signature, sont réservés au rôle Propriétaire côté serveur. L’interface ne bloque pas encore les utilisateurs Administrateur ou Lecture seule lorsqu’ils tentent de les activer, si bien qu’un utilisateur qui n’est pas Propriétaire peut voir une confirmation « enregistré » alors même que la modification n’a pas été appliquée. Si un paramètre ne semble pas être conservé, demandez à un Propriétaire d’effectuer la modification.
Les Propriétaires et les Administrateurs peuvent ajouter des personnes à votre entreprise :
  1. Ouvrez Utilisateurs dans la barre latérale et cliquez sur Ajouter un Utilisateur.
  2. Saisissez son nom et son adresse email, puis choisissez un Niveau de Compte : Administrateur ou Lecture Seule (seul un Propriétaire peut ajouter un autre Propriétaire). La question précédente sur les rôles explique ce que chaque niveau permet.
  3. Cliquez sur Envoyer l’Invitation.
Si l’adresse email n’a pas encore de compte Firma.dev, le compte est créé immédiatement et un mot de passe temporaire s’affiche une seule fois à l’écran. Aucun email d’invitation n’est envoyé : communiquez ce mot de passe à la personne (voir la question suivante). Si la personne a déjà un compte Firma.dev, elle est ajoutée à votre entreprise immédiatement et conserve son mot de passe actuel.
C’est un comportement voulu : ajouter un membre de l’équipe crée immédiatement son compte au lieu d’envoyer une invitation par email. Le mot de passe temporaire du nouvel utilisateur s’affiche une seule fois à l’écran au moment de la création, il n’est pas envoyé par email. Communiquez-lui ce mot de passe pour qu’il puisse se connecter ; il sera ensuite invité à définir son propre mot de passe lors de sa première connexion. Si le mot de passe temporaire est perdu avant d’avoir été utilisé, utilisez Mot de passe oublié sur la page de connexion pour le réinitialiser.
Modifiez votre email de connexion depuis la boîte de dialogue Mon profil (accessible depuis votre avatar ou « Mon profil » dans la barre latérale) ; cela déclenche un flux standard de confirmation par email vers la nouvelle adresse. L’onglet Informations sur l’entreprise de la page Compte comporte également un champ « Email », mais il s’agit d’une adresse de contact distincte, au niveau de l’entreprise, pour la facturation et les notifications : la modifier n’affecte pas votre méthode de connexion. S’inscrire avec un email différent crée toujours un compte distinct ; Firma.dev ne propose aucun moyen en libre-service de fusionner des comptes. Pour fusionner des comptes ou supprimer entièrement votre compte, contactez le support.
Les liens de réinitialisation de mot de passe sont à usage unique et limités dans le temps ; une fois qu’un lien a été ouvert (y compris automatiquement en votre nom), un second clic l’affiche comme expiré ou invalide, et vous devrez en demander un nouveau depuis Mot de passe oublié. Une cause fréquente de consommation d’un lien avant même que vous ne cliquiez dessus est un scanner de sécurité d’email d’entreprise qui ouvre automatiquement les liens des emails entrants ; une boîte mail partagée ou un alias peut également retarder ou filtrer le message. Assurez-vous de demander la réinitialisation pour l’adresse email exacte sous laquelle votre compte est enregistré, et contactez le support si le problème persiste.
Vous intégrez Firma.dev via son API REST, éventuellement associée à ses éditeurs intégrables. Firma.dev fournit également un SDK TypeScript, et publie des guides pas à pas pour des plateformes telles que n8n, Supabase et Lovable, en plus des clients d’outils de codage IA couverts par ses serveurs MCP.Voir : Guide de configuration complet, Signature intégrable, Intégration MCP
L’API couvre l’intégralité du flux de signature électronique, de la création d’une demande de signature à la réception d’un document signé et scellé. Les champs peuvent également être placés à l’aide de balises d’ancrage, avec des règles de conditions et de champs obligatoires, une vérification OTP par email, et un contrôle total sur chaque email envoyé par Firma.dev. Les documents complétés sont scellés sous forme de PDF PAdES-B-LTA avec un certificat d’achèvement, et chaque espace de travail isole la marque, les domaines d’envoi et les modèles d’email d’un client.Voir : Envoi d’une demande de signature, Webhooks, Piste d’Audit
Utilisez l’Aide intégrée : ouvrez Aide dans la barre latérale et posez votre question. Si la réponse ne règle pas le problème, cliquez sur Cela n’a pas répondu à ma question sous la réponse pour soumettre un ticket de support. Le ticket inclut votre conversation, vous n’avez donc pas besoin de la répéter.

​
Tarification et facturation

Un crédit couvre une seule demande de signature, facturée au moment de l’envoi et jamais remboursée par la suite. Un crédit équivaut à une demande de signature (enveloppe), quel que soit le nombre de signataires ou de documents qu’elle contient. Il est déduit au moment de l’envoi de la demande, juste après le départ des emails de signature et avant que la demande ne soit marquée comme envoyée, et non lorsque les signataires terminent. Les crédits ne sont pas remboursés si un signataire refuse de signer ou si la demande expire, et aucun crédit n’est facturé si la validation de l’envoi échoue ou si l’email lui-même échoue à partir.Voir : Guide de configuration complet
Firma.dev fonctionne au paiement à l’usage, sans abonnement, minimum, ni frais par utilisateur. Les crédits n’expirent pas. Les comptes créés avant le dernier changement de tarif de Firma.dev, ou inscrits via le code de parrainage d’un autre client, conservent ce tarif par crédit antérieur et plus bas pendant toute la durée de vie du compte. Un code de parrainage ne conditionne pas l’accès (n’importe qui peut s’inscrire librement), mais il rapporte des crédits bonus aux deux parties lors du premier achat de l’entreprise parrainée.Voir : Guide de configuration complet
Téléchargez vos factures depuis Compte > Crédits et facturation, et ajoutez les informations de votre entreprise avant le paiement. Saisissez le nom de votre entreprise, votre adresse de facturation et votre numéro de TVA à l’étape Ajouter un numéro fiscal du paiement Paddle, avant de payer. Pour corriger une facture déjà émise, contactez le support via Aide dans la barre latérale du tableau de bord avec le numéro de facture, le nom de l’entreprise, l’adresse de facturation et le numéro de TVA. Elle est réémise et affichée via le même lien Voir.Voir : Mises à jour de la plateforme : téléchargements de factures
Ceci est presque toujours causé par un bloqueur de publicités, une extension de confidentialité, ou un filtre réseau d’entreprise empêchant le chargement du script de paiement de Paddle. Firma.dev affiche alors « Failed to load payment system: Failed to load Paddle.js. ». Essayez de désactiver le bloqueur pour ce site, ou ouvrez la page dans une fenêtre de navigation privée ou dans un autre navigateur. Si un achat semble avoir échoué en cours de route, consultez Compte > Crédits et facturation > Historique des transactions pour vérifier s’il a réellement abouti avant de réessayer, afin de ne pas payer deux fois.
Oui, la recharge automatique est disponible. Achetez des crédits à tout moment depuis Compte > Crédits et facturation, et activez la Recharge automatique dans ce même onglet pour acheter automatiquement un lot de crédits défini chaque fois que votre solde descend sous un seuil que vous choisissez. Il n’existe actuellement aucun palier de remise basé sur le volume ; chaque lot de crédits est facturé au tarif standard par crédit de votre compte, quel que soit le montant acheté en une seule fois.Voir : Guide de configuration complet

​
Envoi de demandes de signature

POST /signing-requests crée uniquement un brouillon. Il n’envoie jamais d’email de lui-même, quels que soient vos settings.Voir : Envoi d’une demande de signature : Create vs. create-and-send
Oui, vous pouvez supprimer les emails de signature et d’achèvement propres à Firma.dev et envoyer le lien de signature via votre propre système à la place.
  • settings.send_signing_email: false: supprime l’email de notification de Firma.dev tandis que la demande est quand même envoyée, et cela fonctionne que vous appeliez /send ou create-and-send.
  • settings.send_finish_email: false: désactive l’email d’achèvement de la même manière.
  • reminders: tableau que vous fournissez à la création et qui contrôle les emails de rappel, les demandes basées sur un document n’en recevant aucun par défaut et les demandes basées sur un modèle héritant des rappels du modèle sauf si vous les remplacez.
Voir : Envoi d’une demande de signature : L’indicateur send_signing_email et Envoi d’une demande de signature : Intégrer la vue de signature
L’URL de base correcte est :
Ajoutez le chemin de la ressource à la suite, par ex. .../signing-requests. Les erreurs 404 proviennent souvent de deux sources :
  • https://api.firma.dev/api/v1: un second serveur « Planned » répertorié dans la spécification OpenAPI publique pour une future forme d’API, pas un véritable endpoint, donc un client généré pointé vers celui-ci renvoie une 404 à chaque appel.
  • POST /signing-requests: l’endpoint réel derrière la page de référence « Create Signing Request », et non une route /create-signing-request comme le titre pourrait le laisser penser.
Voir : Authentication: Code Examples
Une charge utile valide comporte une liste recipients et une liste fields ; chaque champ pointe vers un destinataire et une position sur la page.Chaque destinataire nécessite first_name et email. designation est facultatif et vaut Signer par défaut ; vous pouvez aussi le définir sur Approver ou CC. last_name est obligatoire lors de la création depuis un document ou document_id brut avec POST /signing-requests, et facultatif pour les demandes fondées sur un modèle. order est facultatif.Chaque champ nécessite :
  • type: l’un des types de champs pris en charge, qui incluent également radio_buttons, text_area, url, file, et stamp.
  • page_number: la page sur laquelle le champ apparaît.
  • position: x, y, width, height en pourcentages de la page, pas en pixels.
  • recipient_id: le destinataire auquel appartient le champ.
Pour référencer un destinataire que vous n’avez pas encore créé, donnez-lui un id temporaire commençant par temp_ (par exemple temp_alice) et définissez recipient_id sur le champ avec la même valeur. L’API le fait correspondre à un véritable UUID et ne renvoie jamais d’ID temporaire.Il n’existe pas de propriété metadata de premier niveau. Utilisez à la place l’objet custom_fields de chaque destinataire.Voir : Sending a signing request: Recipient Schema et Sending a signing request: Field types
La taille maximale d’un document est de 50 Mo (52 428 800 octets). Téléversez les fichiers volumineux avec le processus en deux étapes :
  • POST /documents: téléverse le fichier et renvoie une upload_url présignée.
  • PUT: envoie le fichier vers cette upload_url.
  • document_id: transmettez cette valeur lors de la création de la demande de signature.
Gardez le base64 en ligne dans document sous environ 5 Mo. Un corps de requête supérieur à 6 291 456 octets renvoie 413 REQUEST_TOO_LARGE. Avant le 13 octobre 2026, la passerelle renvoyait 502. Le serveur MCP n’a pas d’outil de téléversement, donc les fichiers volumineux passent par l’API REST.
Oui, Firma.dev prend en charge le DOCX et le convertit automatiquement en PDF côté serveur avant la création de la demande de signature.
  • POST /signing-requests: accepte un fichier DOCX lorsque vous créez directement une demande de signature.
  • POST /documents: accepte un fichier DOCX lorsque vous téléversez un document séparément.
Ce convertisseur ne restitue que le texte, les titres, les listes et les tableaux. Il supprime entièrement toute image présente dans le DOCX, et il ne charge qu’un jeu de polices de style latin/cyrillique, si bien que le texte dans des écritures de droite à gauche comme l’hébreu ou l’arabe peut ressortir avec des glyphes manquants ou mal rendus.Si votre document contient des images ou une écriture non latine que vous devez préserver exactement, exportez-le d’abord vous-même en PDF (par ex. LibreOffice, ou Google Docs > File > Download > PDF) et envoyez le PDF plutôt que le DOCX.
Non. Les endpoints d’écriture (create, create-and-send, send, resend) n’ont pas d’en-tête Idempotency-Key.Un appel create ou create-and-send réessayé automatiquement peut créer une demande de signature en double, facturée séparément et juridiquement contraignante. Rappeler /send sur une demande déjà envoyée renvoie une erreur au lieu de la dupliquer.Pour éviter les doublons, stockez l’id renvoyé par le premier appel et vérifiez sa présence, ou interrogez les demandes existantes, avant de réessayer.Voir : n8n integration: Other common operations
Non, vous ne pouvez pas modifier l’email d’un destinataire après l’envoi. Annulez et recréez la demande à la place.Vous pouvez annuler silencieusement :
  • POST /signing-requests/{id}/cancel: l’endpoint à appeler pour annuler une demande.
  • notify_signers: false: un paramètre de cet appel d’annulation lui-même, et non un paramètre défini à la création, qui supprime la notification au signataire.
  • settings.send_cancellation_email sur la demande de signature, activé par défaut, doit également être vrai pour qu’un email d’annulation soit envoyé.
Voir : Signing patterns: Error handling: 409 ALREADY_SENT
Oui. Depuis le 13 octobre 2026, un modèle ou une demande de signature peut contenir jusqu’à 20 documents (100 Mo par ensemble). Téléversez chaque fichier avec POST /documents, puis envoyez les identifiants dans l’ordre des documents sous document_ids sur POST /templates, POST /signing-requests ou POST /signing-requests/create-and-send. Envoyez exactement une source de document : document, document_id, document_ids ou template_id.Utilisez les routes /documents sur un modèle ou une demande de signature à l’état de brouillon pour ajouter, remplacer, renommer, réordonner et supprimer chaque document ; une fois qu’une demande de signature est envoyée, terminée, annulée ou refusée, ces modifications renvoient 409 DOCUMENT_SET_LOCKED. Téléchargez chaque document d’une demande de signature avec GET /signing-requests/{id}/documents/{document_id}/download, tel que téléversé ou scellé individuellement.Pour remplacer un document et conserver ses champs, utilisez PATCH .../documents/{document_id} avec un nouveau fichier téléversé ayant le même nombre de pages et les mêmes dimensions de page (à 1 pt près) ; sur une demande de signature, un document placé avec des balises d’ancrage n’est remplacé que si les ancrages du nouveau fichier se résolvent exactement comme ils sont enregistrés. Consultez le journal des modifications de l’API v1.39.0.
GET /signing-requests/{id}/download renvoie le PDF signé sous forme d’URL présignée.Il renvoie une unique download_url présignée de courte durée, valide jusqu’à l’horodatage expires_at : le PDF final pour une demande terminée, ou un instantané de progression partielle pour une demande envoyée qui n’est pas terminée. Pour une demande terminée, ce PDF unique comporte déjà le certificat d’achèvement et les pages de piste d’audit ajoutées au document signé, et cet endpoint ne fournit pas d’URL distincte pour le seul certificat. Pour obtenir des fichiers séparés lorsqu’ils existent, lisez document_only_download_url et certificate_only_download_url dans GET /signing-requests/{id}.Appeler cet endpoint se comporte différemment selon l’état de la demande de signature :
  • 409: renvoyé si vous l’appelez avant que la demande n’ait été envoyée, ou pour une demande terminée tant que son certificat d’achèvement est encore en cours de génération.
  • Pour une demande envoyée qui n’est pas terminée (en cours, expirée, annulée ou refusée) : renvoie un instantané de progression partielle des signataires qui ont terminé jusque-là. Aucun paramètre ne permet de l’activer.
  • 503: renvoyé avec un en-tête Retry-After tant qu’un instantané de progression partielle est encore en cours de génération.
Oui, vous pouvez récupérer l’image de signature d’un signataire et tous les fichiers qu’il a téléversés via l’API.
  • GET /signing-requests/{id}/signers/{signer_id}/signature: renvoie la signature adoptée sous forme d’URI de données data:image/png;base64,....
  • GET /signing-requests/{id}/signers/{signer_id}/initials: renvoie les initiales adoptées de la même manière.
  • GET /signing-requests/{id}/signers/{signer_id}/stamps/{field_id}: renvoie une image de tampon pour le field_id donné, les tampons étant propres à chaque champ.
  • GET /signing-requests/{id}/signers/{signer_id}/files/{field_id}: renvoie une URL de téléchargement présignée, valide 300 secondes, pour un fichier téléversé dans un champ de type file, et non les octets du fichier directement.
  • GET /signing-requests/{id}/fields: filtrez sur type=file pour trouver le field_id d’un fichier téléversé.
Les fichiers téléversés ne sont jamais intégrés dans le PDF signé final ni dans le certificat ; ils n’existent que comme pièces jointes récupérables via ces endpoints.
GET /signing-requests/{id}/fields renvoie tous les champs de la demande ; lisez la propriété value de chaque entrée pour obtenir la valeur résolue, et faites correspondre sur variable_name.Voir : Field Prefilling: Reading field values back

​
Modèles / champs / balises d’ancrage

x, y, width, et height sont des pourcentages de la page, pas des pixels. L’origine est le coin supérieur gauche et y augmente vers le bas.Un champ spécifié manuellement renvoie une erreur 400 lorsque x+width>100 ou y+height>100. Les champs placés par des balises d’ancrage sont en revanche ramenés automatiquement dans les limites de la page.
Placez un texte marqueur littéral dans le document et transmettez un tableau anchor_tags sur une requête de création basée sur un document, jusqu’à 100 balises par requête.Les balises d’ancrage acceptent tous les types de champs, ainsi que dropdown_options, format_rules, multi_group_id, et conditions.
remove_anchor_text rend le texte correspondant invisible dans le flux de contenu du PDF plutôt que de le supprimer.Cela peut échouer sur des polices intégrées/sous-ensemble (CID) ou lorsque le texte marqueur est réparti sur plusieurs opérateurs d’affichage de texte PDF distincts. Lorsque cela se produit, le système dessine automatiquement une boîte blanche uniquement sur la zone du marqueur correspondant, même sans que add_white_background soit défini.
Cette erreur signifie que le texte du marqueur d’ancrage se trouvait à l’intérieur d’un Form XObject PDF ou d’un groupe de transparence non rejoué lors de la lecture des positions de glyphes.Cela se produit généralement dans des documents HTML-vers-PDF, lorsqu’un pipeline d’impression Chromium enveloppe un élément avec une opacity CSS inférieure à 1, ou un transform, à l’intérieur d’un Form XObject de groupe de transparence.L’extracteur rejoue le texte à l’intérieur des contextes de formulaire et de groupe (à l’exclusion des flux d’apparence d’annotation), si bien que les ancres qui s’y trouvent sont détectées.Si cela se reproduit, l’ancre se trouve probablement dans une construction de police/géométrie malformée ou inhabituelle. Réexportez le PDF source avec un encodage de police standard.
Définissez format_rules.prefilledData sur un champ pour le remplir automatiquement et le verrouiller à partir des données du destinataire.Le signataire peut quand même modifier la valeur si vous définissez également format_rules.prefilledEditable sur true.Cela fonctionne de la même manière sur les champs placés par des balises d’ancrage, puisque les balises d’ancrage acceptent elles aussi format_rules.
Les champs de texte rétrécissent automatiquement pour s’adapter à la boîte du champ lorsqu’une valeur déborde, jusqu’à un plancher par défaut de 8px.Définissez plutôt format_rules.fontSize pour une taille de départ explicite. Si le texte est encore coupé, agrandissez le champ ou passez à un textarea.
Attribuez le même multi_group_id à un ensemble de champs pour les relier en un groupe.
  • radio_buttons: les champs partageant un multi_group_id forment un groupe mutuellement exclusif.
  • checkbox: les champs partageant un multi_group_id forment un groupe indépendant.
La valeur stockée d’une option radio sélectionnée est la chaîne littérale "true".Un champ checkbox s’affiche comme une case à cocher native, et non comme une icône de coche personnalisée.
visibility_conditions et required_conditions sont des objets ConditionSet sur un champ qui référencent le field_id d’un autre champ du même destinataire.
  • GET /templates/{id}/fields: renvoie les deux propriétés, même si le schéma OpenAPI public les omet.
Lorsque vous créez une demande de signature à partir d’un modèle (flux en deux étapes, create-and-send, ou /duplicate), les deux jeux de conditions sont copiés et leurs références field_id sont remappées.
Ajoutez chaque champ individuellement ; il n’existe pas d’option groupée pour placer un champ sur chaque page.Pour des initiales sur chaque page, ajoutez un champ initial par page dans le tableau fields, chacun avec son propre page_number. Un même destinataire peut avoir plusieurs champs obligatoires du même type, y compris plusieurs champs signature.
Utilisez un champ date pour remplir automatiquement la date de signature.Le champ s’affiche en lecture seule dans la vue de signature et se remplit avec la date locale du navigateur du signataire au moment où il termine, et non avec un fuseau horaire serveur.
  • date_signing_default: true: active le remplissage automatique ; il n’existe pas de type date_signed distinct.
  • timezone: le paramètre de l’espace de travail vérifié en premier pour les horodatages du certificat, avec UTC par défaut tant que vous ne le définissez pas.
  • default_timezone: le repli au niveau de l’entreprise vérifié ensuite, également avec UTC par défaut tant que vous ne le définissez pas.
Non, les modèles ne sont pas partagés entre les espaces de travail, pas même au sein de la même entreprise.
  • POST /templates/{id}/copy: copie en profondeur les champs, les destinataires, la liste CC, les rappels, les définitions de champs personnalisés et le document du modèle vers un autre espace de travail, à l’aide d’une clé API de niveau entreprise (protégée).
  • workspace_id: l’espace de travail cible que vous transmettez dans le corps de la requête.
  • POST /templates/{id}/duplicate: crée à la place une nouvelle demande de signature à partir du modèle, pas une copie du modèle.

​
Expérience de signature

Oui, vous pouvez rediriger le signataire ou personnaliser la page d’achèvement après la signature.
  • completion_redirect_url: redirige le signataire une fois qu’il a terminé de signer.
  • completion_title: personnalise le titre de la page d’achèvement, défini aux côtés de l’URL de redirection.
  • completion_message: personnalise le message de la page d’achèvement, défini aux côtés de l’URL de redirection.
  • signing.completed: l’événement à écouter à la place, si vous intégrez la vue de signature.
Voir : Personnalisation de la page d’achèvement (journal des modifications de l’API v1.34.0) et Signature intégrable - Événements postMessage
Vous pouvez renommer les boutons de signature et en masquer deux. Vous ne pouvez pas masquer le sélecteur de langue.Personnalisez le texte par langue avec signing_button_label_overrides, en utilisant des clés de traduction comme common.finish, signing.approveAndFinish, signing.nextRequiredField, signing.saveAndFinishLater et signing.decline.confirm. Depuis v1.40.0, définissez allow_decline ou show_save_for_later sur false pour masquer Refuser de signer ou Enregistrer et terminer plus tard. Le sélecteur de langue reste toujours affiché.disable_guided_navigation désactive le défilement automatique vers le champ suivant, affiché dans le tableau de bord sous le nom « Désactiver le défilement automatique ».Voir : Paramètres de l’espace de travail
Oui, vous pouvez à la fois la désactiver et personnaliser son texte. Le verrou d’acceptation des conditions peut être activé ou désactivé par espace de travail, ou par défaut au niveau de l’entreprise. Il est activé par défaut. Le texte de la bannière de consentement et la page de conditions associée sont entièrement personnalisables par langue depuis Paramètres de l’espace de travail/de l’entreprise > Conditions, pour chacune des 15 langues prises en charge. Tout ce que vous ne définissez pas retombe d’abord sur le texte personnalisé de votre entreprise, puis sur la bannière de conditions intégrée propre à Firma.dev, déjà localisée dans les 15 langues.Voir : Validité Juridique et Conformité eIDAS
Oui, les signataires peuvent corriger leur nom ou leur entreprise avant de signer sur des liens transférés.Définissez identity_editable_fields sur la demande de signature ou le modèle, par exemple name et company, pour que le signataire puisse modifier ses propres informations avant de signer. Une boîte de dialogue de correction apparaît juste après qu’il accepte les conditions, et chaque modification est écrite dans la piste d’audit.Voir : Scénarios de demandes de signature - Schéma : Deuxième signataire dynamique
Les signataires peuvent dessiner ou saisir leur signature, vous pouvez exiger des signatures manuscrites, et le cyrillique est pris en charge.La saisie détecte automatiquement l’écriture du signataire (latine, cyrillique, grecque, japonaise, coréenne) à partir de son nom et propose des styles de police correspondants ; il n’existe pas d’option distincte de téléversement d’image. Définissez hand_drawn_only sur true sur la demande de signature ou le modèle pour retirer l’onglet Saisir et imposer le dessin.Firma.dev ne prend pas en charge les certificats X.509 fournis par le signataire ; il applique son propre sceau PAdES au document complété côté serveur.Voir : Scénarios de demandes de signature
Demandez au signataire d’effectuer un rechargement forcé de la page. Si cela n’aide pas, ouvrez le lien dans une version récente de Chrome, Firefox ou Safari avec les bloqueurs de contenu et de publicités désactivés, car les bloqueurs peuvent interférer avec les scripts de la page de signature. Sur Safari iOS, assurez-vous qu’iOS et Safari sont à jour puis réessayez ; les versions plus anciennes pouvaient manquer de mémoire sur des PDF très volumineux ou en haute résolution.
Oui, ajoutez ?zoom= à l’URL de signature.Voir : Signature intégrable - Paramètres d’URL
Le message d’erreur d’un lien de signature dépend de l’état de la demande de signature : pas encore envoyée, expirée, déjà complétée par ce destinataire, ou cassée, mal saisie, ou annulée.
  • Not sent yet: ouvrir le lien avant que l’expéditeur n’ait réellement envoyé la demande affiche ce message.
  • Expired: la fenêtre expiration_hours de la demande, mesurée à partir du moment de l’envoi, est dépassée ; comme une demande envoyée ne peut plus être modifiée, l’expéditeur doit créer une nouvelle demande plutôt que d’en prolonger l’expiration.
  • Already signed: ce destinataire précis a terminé sa signature ; cela est propre à son propre lien unique, donc cela ne se produit pas si un autre signataire ouvre son propre lien.
  • Invalid: un lien cassé ou mal saisi, ou un lien correspondant à une demande annulée, produit sa propre erreur distincte plutôt que « already signed ».
Il n’existe pas de mode intégré « n’importe quel signataire » : votre application doit décider qui signe avant de créer la demande. Un sceau d’organisation peut appliquer automatiquement la contresignature de votre entreprise, mais chaque signataire individuel doit ouvrir son propre lien et compléter le parcours de signature.Voir : Scénarios de demandes de signature - Scénario : Signature en parallèle
Rien ne casse. Le lien de signature de chaque destinataire est identifié par son propre ID de destinataire, pas par son email, donc deux signataires peuvent partager la même adresse email sans conflit, et transférer un lien ne permet pas à quelqu’un d’autre de devenir un signataire différent. Si un lien parvient à la mauvaise personne, identity_editable_fields permet au signataire réel de corriger sa propre identité avant de signer, et cette correction est enregistrée dans la piste d’audit.Voir : Scénarios de demandes de signature - Scénario : Deuxième signataire dynamique
Utilisez Code QR sur la page de signature dans les paramètres de l’espace de travail pour contrôler la signature par code QR sur téléphone.Les codes QR sont activés par défaut ; la désactivation de ce paramètre les supprime. Le code QR apparaît sur la page de signature ; ajoutez le placeholder {{signing_qr_code}} aux modèles d’invitation pour l’inclure dans les emails.Voir : Paramètres de l’espace de travail : Code QR dans les emails

​
Vérification d’identité (OTP)

Un code OTP est valide pendant 10 minutes, avec jusqu’à 3 tentatives avant que vous ayez besoin d’en demander un nouveau.Le renvoi est limité à une fois toutes les 60 secondes, et ces valeurs sont fixes : elles ne sont configurables ni par espace de travail ni par demande.Une fois que vous avez vérifié un code, Firma.dev stocke un jeton de session dans votre navigateur et émet une nouvelle session de signature de 4 heures à chaque visite suivante, donc rouvrir le même lien de signature dans le même navigateur pendant cette fenêtre ignore l’invite OTP. Cette session glissante est plafonnée à 12 heures depuis votre dernière vérification réussie, après quoi il vous sera demandé de vérifier à nouveau, quelle que soit l’activité.
Oui. Chaque ligne de signataire du certificat de finalisation comporte une ligne Authentification : « Lien par courrier électronique » pour un signataire qui a signé sans code à usage unique, « Lien par courrier électronique + code à usage unique (code vérifié le <heure>) » pour un signataire qui a saisi le code. La ligne Identité de la demande indique la méthode commune, ou « Mixte (voir signataires) » lorsque les signataires diffèrent. Exceptions : les certificats émis avant la mise en production de cette fonctionnalité affichent « Lien par courrier électronique » uniquement dans la ligne Identité, sans ligne Authentification par signataire ; les signataires qui ont vérifié avant la mise en production sans recharger la page impriment « Lien par courrier électronique » ; un signataire qui a vérifié le code avant la mise en production et n’a rechargé la page qu’après imprime « Lien par courrier électronique + code à usage unique » sans l’heure « (code vérifié le …) », pendant au plus douze heures après la mise en production ; une demande dont l’exigence de code à usage unique a été désactivée pendant qu’un signataire était en cours peut imprimer « Lien par courrier électronique » (le lien n’est conservé que tant que la session de ce signataire est reconduite) ; et lorsque le serveur ne peut pas confirmer le lien à la finalisation (par exemple un échec de recherche), le certificat imprime « Lien par courrier électronique » plutôt que de deviner.
Vous pouvez définir la langue de l’email OTP par demande, mais pas son texte. Définissez language sur la demande de signature elle-même pour remplacer les valeurs par défaut de l’espace de travail et de l’entreprise pour les emails destinés au signataire de cette demande, email OTP compris. Les modèles d’email personnalisés ne peuvent pas modifier le texte de l’email OTP, mais vous pouvez ignorer l’OTP entièrement pour une demande en définissant settings.require_otp_verification sur false.Voir : Localisation, Marque blanche
Non. Firma.dev prend actuellement en charge uniquement l’OTP par email pour la vérification d’identité du signataire ; il n’existe pas d’intégration OTP par SMS ou eID national (BankID, MitID, FranceConnect ou similaire). L’OTP par email est inclus sans coût supplémentaire dans la tarification forfaitaire par enveloppe de Firma.dev. Ceci n’est mentionné nulle part comme un élément de la feuille de route à court terme, considérez-le donc comme non pris en charge actuellement plutôt que comme quelque chose de prévu.

​
Webhooks

Cela signifie généralement que l’interrupteur webhook au niveau du compte est désactivé, même si l’espace de travail affiche le statut activé sans aucun échec.Activez-le dans Paramètres > Webhooks, ou via l’API :
  • PATCH /workspaces/{id}: définissez webhook_enabled sur true dans le corps de la requête pour activer les webhooks sans passer par le tableau de bord.
  • ignore_company_webhooks: assurez-vous que ce paramètre n’est pas true sur l’espace de travail ; il exclut silencieusement l’espace de travail des webhooks de l’entreprise.
Le bouton de test du tableau de bord contourne l’interrupteur maître, ce qui explique pourquoi les tests réussissent alors que les événements réels sont ignorés sans aucun échec.Voir : Webhooks
Les webhooks au niveau de l’entreprise et de l’espace de travail diffèrent par leur secret de signature, leur comportement d’exclusion, et la façon dont l’événement de consultation se déclenche.
  • Secrets: les webhooks au niveau de l’entreprise et de l’espace de travail ont chacun leur propre secret de signature.
  • ignore_company_webhooks: permet à un espace de travail de s’exclure entièrement des webhooks de son entreprise, sans affecter les autres espaces de travail.
  • signing_request.viewed: se déclenche uniquement lors de la première consultation d’un destinataire, pas à chaque ouverture ultérieure.
Voir : Webhooks, Webhooks, Webhooks
Firma.dev ne suit pas les redirections HTTP lors de la livraison des webhooks ; il s’agit d’une protection SSRF délibérée, donc un point de terminaison qui redirige fait échouer la livraison purement et simplement. Enregistrez l’URL exacte que votre serveur sert ; une différence de schéma, un sous-domaine www, le chemin, ou une barre oblique finale manquante ou en trop fait échouer chaque tentative de livraison.Voir : Webhooks - Dépannage
Votre point de terminaison doit répondre avec un 2xx en moins de 5 secondes ; les livraisons échouées sont automatiquement retentées, et le point de terminaison est désactivé après 50 échecs consécutifs. Vous pouvez retenter un seul événement depuis le journal d’événements du tableau de bord, mais il n’existe pas de renvoi en masse, et les événements antérieurs à la création du webhook ne sont jamais réinjectés rétroactivement.Voir : Webhooks - Comportement de nouvelle tentative
Non, utilisez les webhooks plutôt que d’effectuer du polling pour les changements de statut.
  • GET /signing-requests/{id}: n’effectuez pas de polling sur ce point de terminaison pour le statut ; les webhooks poussent les mises à jour à la place.
Voir : Limites de débit, Webhooks

​
Livraison des emails et modèles

RECIPIENT_EMAIL_SUPPRESSED (HTTP 422) signifie que le destinataire figure sur la liste de suppression de Firma.dev ; contactez le support pour débloquer une adresse.Voir : Délivrabilité des E-mails : L’erreur RECIPIENT_EMAIL_SUPPRESSED, Délivrabilité des E-mails : Demander la levée de suppression
Le nom de l’expéditeur provient du nom de l’espace de travail, ou à défaut du nom de l’entreprise. L’adresse utilise votre domaine d’envoi vérifié ; définissez sa partie locale avec email_local_part au niveau de l’entreprise ou de l’espace de travail.Voir : Adresse d’expéditeur personnalisée
Contrôlez ces éléments via l’objet settings de la demande de signature :
  • send_finish_email: false: arrête l’email de finalisation.
  • attach_pdf_on_finish: false: envoie un lien de téléchargement au lieu de joindre le PDF.
  • document_only_download_url: partage le document sans le certificat, au lieu de final_document_download_url.
  • certificate_only_download_url: renvoie uniquement le certificat.
  • allow_download: false: désactive entièrement les liens de téléchargement, indépendamment de attach_pdf_on_finish.
Les destinataires en copie reçoivent le document finalisé en pièce jointe email, avec les mêmes paramètres que la copie du signataire.Voir : Désactiver les emails Firma.dev
Les modèles personnalisés utilisent la syntaxe {{placeholder}}.L’ancienne syntaxe [bracket] fonctionne aussi et ne fait pas de distinction de casse ; un placeholder non résolu s’affiche comme vide, pas comme du texte brut.
  • {{team_name}}: un alias de {{workspace_name}}.
  • {{team_email}}: un alias de {{workspace_email}}.
  • {{download_link}}: ne se résout que dans les emails de finalisation.
Non, les modèles ne varient pas par langue : un seul modèle s’applique à tous les destinataires, donc des modèles à la marque personnalisée par langue nécessitent un espace de travail séparé pour chacune. Il n’existe pas d’aperçu en direct ni de variables personnalisées par demande.Voir : Modèles d’email personnalisés
Oui, via l’API ; ce paramètre n’est pas encore exposé dans le tableau de bord.
  • timezone: un fuseau horaire IANA défini sur l’espace de travail via l’API des paramètres.
  • default_timezone: le repli au niveau de l’entreprise lorsque le fuseau horaire de l’espace de travail n’est pas défini.
Les placeholders tels que {{expiration_date}} dans les emails de signature utilisent ce fuseau horaire et la langue de l’email. L’UTC reste la valeur par défaut lorsqu’aucun des deux n’est défini.Voir : Fuseaux horaires pris en charge
La langue est déterminée d’abord par la demande de signature, puis par l’espace de travail, puis par l’entreprise.Une entreprise ou un espace de travail créé via l’API utilise en par défaut tant que vous ne définissez pas language explicitement. Définissez-le sur l’espace de travail, ou transmettez language dans la demande, et les nouveaux emails aux signataires l’utiliseront.Voir : Paramètres de langue des emails

​
Domaines d’envoi personnalisés

Configurer un domaine d’envoi personnalisé nécessite quelques enregistrements DNS ajoutés en deux étapes : un pour vérifier la propriété, puis quelques autres pour finaliser. Aucun enregistrement MX n’est nécessaire à aucune étape, puisque Firma.dev envoie uniquement des emails via le domaine et ne les reçoit jamais.Voir : Domaines personnalisés - Enregistrements DNS nécessaires
Un statut “Conflit de Domaine” (ou un statut “Configuring” qui reste bloqué) signifie que le domaine est déjà enregistré sous un autre compte Resend, souvent le vôtre ; la solution consiste à utiliser un sous-domaine dédié comme sign.yourcompany.com, qui se vérifie indépendamment. Supprimer le domaine de Firma.dev libère le propre enregistrement de Firma.dev pour une réutilisation ailleurs, mais n’a aucun effet sur un enregistrement dans le compte Resend de quelqu’un d’autre.Voir : Domaines personnalisés - Vous utilisez déjà Resend pour votre propre messagerie ?
Appelez à nouveau verify-dns ; il vérifie en direct à chaque fois, donc un incident transitoire peut signaler le domaine comme non vérifié même lorsque le DNS est correct.Voir : Domaines personnalisés - États de vérification, Domaines personnalisés - Bizarrerie d’affichage connue
Un domaine vérifié passe à “Failed” lorsque ses enregistrements DNS cessent d’être valides. Firma.dev ne le marque comme invalide qu’après deux vérifications automatiques consécutives en échec, pas dès le premier incident isolé, pour éviter les basculements sur un incident transitoire. Tant qu’un domaine est en échec ou pas encore vérifié, Firma.dev envoie automatiquement depuis son propre domaine par défaut plutôt que le vôtre.Voir : Domaines personnalisés - Un domaine vérifié affiche ensuite “Failed”
Oui, ajoutez et vérifiez le domaine séparément dans chaque espace de travail où vous souhaitez l’utiliser.Voir : Domaines Personnalisés, Marque Blanche - Domaines d’email personnalisés

​
Validité juridique / certificats / sécurité

Firma.dev fournit une Signature Électronique Avancée (AES) au sens de l’article 3(11)/26 d’eIDAS, atteignant le seuil d’admissibilité d’eIDAS et les exigences de l’ESIGN Act/UETA pour la plupart des contrats ; Firma.dev n’est pas un Prestataire de Services de Confiance Qualifié et n’émet pas de Signatures Électroniques Qualifiées. Le sceau lui-même est PAdES-B-LTA (Baseline Long-Term Archival), émis depuis la propre autorité de certification de Firma.dev, avec un horodatage RFC 3161 intégré.Voir : Validité Juridique et Conformité eIDAS - Ce que fournit Firma.dev
Le sceau numérique de Firma.dev est émis par la propre autorité de certification de Firma.dev, qui ne remonte ni à l’Adobe Approved Trust List (AATL) ni à l’EU Trusted List (EUTL), donc Acrobat et les lecteurs similaires n’afficheront pas la coche verte automatique ; le sceau lui-même reste entièrement valide. Vérifiez-le dans le panneau de signature de votre lecteur PDF, ou indépendamment sur app.firma.dev/validate-signature.Voir : Validité Juridique et Conformité eIDAS - Pourquoi il n’y a pas de coche verte dans Adobe Acrobat
Vos données restent entièrement au sein de l’UE, et Firma.dev n’est pas certifié SOC 2 ni ISO 27001, bien que ses pratiques s’alignent sur les deux référentiels.Voir : Sécurité et Conformité - Résidence des données
Vous pouvez supprimer une demande de signature non envoyée (brouillon) à tout moment, depuis le tableau de bord ou via l’API :
Une fois qu’une demande a été envoyée, elle ne peut plus être supprimée, seulement annulée. Un document signé et complété est un enregistrement légal : les données capturées par un signataire ne sont jamais modifiées après la signature, et il n’existe pas de point de terminaison en libre-service pour retirer les données d’un seul signataire. Si vous avez besoin de la suppression d’une demande de signature complétée pour satisfaire une demande de protection des données, contactez le support via Aide dans la barre latérale du tableau de bord.
Le certificat de complétion est généré dans la langue configurée de votre espace de travail, pas dans la langue individuelle du signataire ni selon un remplacement au niveau de la demande de signature, et oui, il peut afficher votre logo. Il utilise une chaîne de repli : logo de l’espace de travail, puis logo de l’entreprise, puis logo par défaut de Firma.dev, et il imprime le propre nom de l’espace de travail. Les horodatages du certificat utilisent le fuseau horaire configuré de l’espace de travail, avec repli sur l’UTC si aucun n’est défini.
Non, et ce n’est pas nécessaire. Firma.dev applique son sceau PAdES-B-LTA une seule fois, au moment de la signature. Le profil LTA intègre dans le PDF lui-même la chaîne de certificats complète, un horodatage de confiance et les données de révocation : la signature emporte donc tout ce dont un vérificateur a besoin et reste auto-validable sur le long terme, sans nouvel horodatage de votre part. Si une signature est contestée, les responsabilités liées à l’identité du signataire, au consentement et à la conservation des enregistrements sont énoncées dans les Conditions Générales d’Utilisation de Firma.dev.Voir : Validité Juridique : Ce que fournit Firma.dev, Piste d’Audit
Non, vous ne pouvez pas supprimer l’en-tête Signing Request ID du PDF signé.Signing Request ID: <id> est dessiné sur chaque page du PDF signé et du certificat de complétion, en petit texte gris près de la marge supérieure ; il n’existe aucun paramètre d’espace de travail ou d’API pour le désactiver.L’en-tête est dessiné avec une police intégrée, de sorte que les documents scellés passent la validation PDF/A-2b.
Firma.dev convient à la plupart des cas d’usage en France dans le cadre d’eIDAS et du RGPD, mais pas aux données de santé soumises à l’HDS : Firma.dev ne détient pas la certification HDS (hébergement de données de santé). Les signatures sont scellées au format PAdES-B-LTA. Au titre du RGPD, Firma.dev agit comme sous-traitant ; l’accord de traitement des données est publié et s’applique à tous les clients, incorporé aux Conditions Générales par référence.Voir : Sécurité, Validité juridique et conformité eIDAS

​
Espaces de travail et multi-tenant

Oui, donner à chaque client final son propre espace de travail est la configuration par défaut recommandée par Firma.dev pour les plateformes multi-tenant ; les données d’un espace de travail ne sont jamais visibles depuis un autre. Il n’y a pas de limite au nombre d’espaces de travail que vous pouvez créer sous une même entreprise, et aucun coût supplémentaire par espace de travail.Voir : Architecture Multi-Tenant - Vue d’ensemble de l’architecture : entreprise → espaces de travail, Espaces de Travail
Chaque entreprise dispose exactement d’un espace de travail par défaut, créé automatiquement à l’inscription et marqué protected.Il est destiné à être géré depuis le tableau de bord plutôt que via l’API ; appeler un point de terminaison de gestion sur celui-ci avec une clé API standard renvoie un 403 avec le code PROTECTED_WORKSPACE.Pour les paramètres à l’échelle du compte, utilisez :
Ce point de terminaison accepte default_timezone et language, entre autres champs. Pour tout ce que vous devez gérer directement via l’API, créez plutôt des espaces de travail séparés, non protégés.Voir : Espaces de travail : cas particuliers et dépannage, Paramètres de l’espace de travail : mettre à jour les paramètres de l’espace de travail

​
Marque blanche et intégration

Vous pouvez mettre en marque blanche les emails de demande de signature, le texte d’acceptation des conditions du signataire, ainsi que la page de signature et les intégrations, mais api.firma.dev lui-même ne peut pas être proxifié sous votre propre domaine ; seul le domaine d’envoi d’email est personnalisable. Le certificat de complétion peut également être mis en marque blanche, votre logo remplaçant celui de Firma.dev. show_custom_branding_only retire uniquement la ligne de contact du support Firma.dev des emails ; cela ne retire pas la présence de Firma.dev de la page de signature elle-même.
Définissez les couleurs et un logo de l’espace de travail avec ces deux points de terminaison :
Ces paramètres s’appliquent à l’ensemble de la page de signature, des intégrations, et des emails de signature.Voir : Marque Blanche - Thème de couleurs
Définissez initialZoom pour contrôler directement le zoom initial de l’éditeur de modèles intégré.autoFit (booléen) est l’alternative ; initialZoom (nombre) est prioritaire lorsque les deux sont définis. Chaque canevas de document prend en charge le panoramique via un glissement au bouton central de la souris, laissant le clic gauche libre pour l’interaction avec les champs.Les URL de documents signés expirent après 1 heure. L’éditeur de modèles intégré demande automatiquement une nouvelle URL et retente jusqu’à 3 fois au lieu d’échouer.Si les téléchargements sont bloqués, vérifiez la présence d’un attribut sandbox sur votre propre page ; les exemples d’intégration de Firma.dev n’en définissent aucun.Voir : Éditeur de modèles intégrable
Aucun des deux n’est actuellement pris en charge. Les intégrations de Firma.dev (l’éditeur de modèles, l’éditeur de demande de signature, et la page de signature) n’acceptent pas de CSS personnalisé, et il n’existe pas d’option pour afficher uniquement un champ de signature au lieu du document complet. Si cela bloque votre intégration, partagez votre cas d’usage avec le support Firma.dev.

​
Outils / SDK / limites

Firma.dev fournit deux serveurs MCP, le Data MCP pour l’accès au compte et le Docs MCP pour la consultation de la documentation ; la plupart des développeurs se connectent aux deux.Voir : Intégration MCP - Configuration
Firma.dev propose un SDK officiel, le client TypeScript @firma-dev/sdk, généré à partir de la même spécification OpenAPI que la référence de l’API :
Il n’existe pas de SDK Python officiel ni d’engagement publié sur la feuille de route pour en créer un ; appelez directement l’API REST, par exemple avec la bibliothèque requests.Voir : SDK TypeScript pour l’API Firma.dev - Installation
Les limites de débit sont appliquées par clé API et varient selon l’opération que vous appelez.Voir : Limites de Débit - Niveaux de Limite de Débit
Cette erreur côté client signifie que la requête de votre navigateur vers une fonction Edge n’a jamais atteint le serveur :
Elle provient du SDK JS de Supabase, par exemple à cause d’un bloqueur de publicités, d’un filtre DNS, d’une connexion hors ligne, ou d’un blocage CORS ; il s’agit d’une classe d’erreur différente d’une véritable réponse d’erreur provenant de la fonction elle-même.Sur la page de signature de Firma.dev, cela provient le plus souvent d’un appel analytique en arrière-plan, qui échoue silencieusement et n’affecte pas votre capacité à consulter ou signer le document.Si cela se produit sur un appel qui bloque réellement votre intégration plutôt que sur de l’analytique, vérifiez vos conditions réseau avant de le traiter comme une erreur côté Firma.dev.

​
Pour les signataires (vous avez reçu un document)

Par défaut, tout le monde sur la demande de signature, y compris les destinataires CC, reçoit par email une copie du document complété une fois que chaque signataire a terminé, pas immédiatement après votre propre signature. L’email joint le PDF automatiquement lorsqu’il fait moins de 8 Mo ; les fichiers plus volumineux arrivent plutôt sous forme de lien de téléchargement. Il n’existe pas de connexion ni de tableau de bord signataire pour récupérer vous-même vos documents passés, donc si vous avez besoin d’une copie avant que tout le monde ait terminé, demandez-la à la personne qui vous l’a envoyée (nommée dans votre email d’invitation).
Contactez l’expéditeur nommé dans votre email d’invitation. Firma.dev est la plateforme de signature électronique qu’il a utilisée pour envoyer le document, pas une partie à l’accord, donc Firma.dev ne peut pas répondre à des questions sur ses conditions, renvoyer un lien expiré, ou agir au nom de l’expéditeur. Si vous n’avez pas encore terminé de signer, vous pouvez plutôt refuser la demande ; une fois que vous avez signé, cette signature fait partie de l’enregistrement légal permanent et ne peut être annulée par personne, y compris le support de Firma.dev. Signer est toujours gratuit pour vous : seul le compte de l’expéditeur est facturé.