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.
  • Owner : 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.
  • Owner and Admin : peuvent tous deux gérer les webhooks, les domaines personnalisés, ainsi que les paramètres d’espace de travail ou d’entreprise, inviter ou retirer des utilisateurs (bien qu’un Admin ne puisse pas créer ni promouvoir un autre Owner), et créer des demandes de signature.
  • View Only : 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 Owner côté serveur. L’interface ne bloque pas encore les utilisateurs Admin ou View Only lorsqu’ils tentent de les activer, si bien qu’un utilisateur autre qu’Owner 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 Owner d’effectuer la modification.
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

​
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, envoyez un email à support@firma.dev 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, email, et designation (Signer, Approver, ou CC). last_name et order sont optionnels.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, sinon la requête peut échouer avec une 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.
  • send_cancellation_email: un paramètre d’espace de travail qui doit également être activé pour qu’un email d’annulation soit envoyé.
Voir : Signing patterns: Error handling: 409 ALREADY_SENT
Non, une demande de signature possède exactement un seul document source.Vous fournissez exactement l’un des éléments suivants :
  • document: contenu base64 en ligne.
  • document_id: l’ID renvoyé par une requête POST vers /documents.
  • template_id: l’ID d’un modèle existant.
Ces options sont mutuellement exclusives ; pour combiner plusieurs fichiers dans un seul flux de signature, fusionnez-les vous-même en un seul PDF avant de créer la demande.Pour les modèles en particulier, il n’est pas nécessaire de recréer un modèle pour mettre à jour son fichier sous-jacent. Une requête POST vers /templates/{id}/replace-document remplace le PDF d’un modèle tout en préservant tous les placements de champs existants. Le fichier de remplacement doit avoir le même nombre de pages et des dimensions de page correspondantes (à 1 pt près) que l’original, de sorte qu’il met à jour le contenu sur la mise en page existante plutôt que de joindre un document sans rapport.
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, pour le PDF final. 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 de téléchargement distincte pour le seul certificat.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.
  • allow_partial_download: lorsqu’il est activé, permet d’obtenir un instantané de progression partielle pendant que la signature est encore en cours.
  • 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, mais pas les masquer ni masquer le sélecteur de langue.Renommez le texte des boutons par langue avec signing_button_label_overrides, ce qui couvre Terminer, Approuver et terminer, Champ obligatoire suivant, Enregistrer et terminer plus tard, et la boîte de dialogue Refuser. Le bouton Refuser, le bouton Enregistrer et terminer plus tard, et le sélecteur de langue s’affichent toujours et ne peuvent pas être masqués.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 14 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 14 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 ».
Non, dans les deux cas. Il n’existe pas de mode intégré « n’importe quel signataire » : votre application doit décider qui signe précisément avant de créer la demande. Il n’existe pas non plus de signature automatique ou sans supervision au nom de votre propre entreprise ; chaque signataire, y compris une personne de votre équipe, doit ouvrir son 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
Activez Code QR sur la page de signature dans les paramètres de l’espace de travail pour activer la signature par code QR sur téléphone.Cela définit show_qr_code sur true. Ajoutez le placeholder {{signing_qr_code}} à vos modèles d’email pour que le code QR apparaisse.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é.
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 support@firma.dev.
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. Firma.dev applique son sceau PAdES-B-LTA une seule fois, au moment de la signature, et ne le retimbre ni ne le renouvelle jamais par la suite ; pour des fenêtres de conservation très longues, appliquez votre propre nouvel horodatage lorsque vous archivez le fichier. 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 ; un accord de traitement des données est disponible sur demande auprès de support@firma.dev.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é.