Nouveautés sur Firma.dev : personnalisez votre page de signature en marque blanche jusqu'aux boutons

La page de signature de Firma.dev porte déjà votre image de marque : votre logo, vos couleurs, vos conditions pour les signataires, vos e-mails et votre page de confirmation. Depuis l'API v1.40.0, publiée le 17 octobre 2026, elle applique également vos règles concernant les actions qu'un signataire peut y effectuer. Deux nouveaux paramètres permettent de masquer les boutons Refuser de signer et Enregistrer et terminer plus tard sur les pages de signature hébergées et intégrées, de sorte qu'une plateforme SaaS exécutant une signature intégrée au sein de son propre produit décide désormais des actions offertes à ses signataires.

Nouveau : choisissez les boutons visibles par vos signataires

Cette version ajoute deux commutateurs. allow_decline contrôle le bouton Refuser de signer et show_save_for_later contrôle Enregistrer et terminer plus tard. Tous deux s'appliquent à la page de signature hébergée ainsi qu'à l'iframe de signature intégrée, et sont tous deux visibles par défaut, garantissant que vos pages de signature restent exactement telles quelles tant que vous n'avez pas défini de valeur.

Le masquage de Refuser de signer est strictement appliqué. Lorsque allow_decline est défini sur false, Firma.dev rejette tout refus sur cette demande de signature, aussi bien pour les signataires que pour les approbateurs, et la demande ne peut être interrompue qu'en l'annulant... ce qui confie la décision de refus à votre produit. Masquer Enregistrer et terminer plus tard supprime simplement le bouton.

Votre page de signature, en marque blanche de bout en bout

La visibilité des boutons constitue la couche la plus récente d'un ensemble de fonctionnalités en marque blanche que les plateformes SaaS utilisent déjà pour faire en sorte que la signature intégrée ressemble et fonctionne comme une partie intégrante de leur propre application. Les commandes actuelles, regroupées selon l'endroit où le signataire les rencontre :

Sur la page de signature

• Boutons de la page de signature (nouveau) : afficher ou masquer Refuser de signer et Enregistrer et terminer plus tard.

• Libellés des boutons : renommez neuf boutons de l'interface de signature par langue avec signing_button_label_overrides, y compris Refuser de signer et Enregistrer et terminer plus tard. En savoir plus dans libellés personnalisés des boutons de signature.

• Thème de couleurs : 11 paramètres hexadécimaux color_* au niveau de l'entreprise et de l'espace de travail. Cinq d'entre eux personnalisent également le thème des éditeurs intégrés.

• Paramètres d'affichage : cadre de signature, filigrane partiel, code QR, vérification OTP par e-mail, acceptation des conditions, navigation guidée et téléchargement préalable à la signature.

• Conditions pour les signataires : votre propre déclaration de consentement par langue, avec un lien facultatif vers les conditions.

• Couleurs d'arrière-plan des champs et interface utilisateur de signature en 15 langues, choisie à l'aide du paramètre lang.

Intégration

• Signature intégrée dans une iframe qui émet les événements postMessage signing.started, signing.completed, signing.declined et signing.error. Le guide de démarrage rapide de l'API de signature électronique intégrée en détaille le fonctionnement.

• Éditeurs de modèles et de demandes de signature intégrables avec commandes de thème et de fermeture.

E-mails

• Un domaine d'envoi personnalisé vérifié avec SPF, DKIM et DMARC, ainsi que votre propre partie locale d'adresse d'expéditeur.

• Votre logo (PNG ou JPEG, jusqu'à 2 Mo) sur les e-mails de signature et les certificats.

• Modèles d'e-mails personnalisés au niveau de l'entreprise ou de l'espace de travail, plus des commutateurs par demande permettant de désactiver les e-mails de signature, de finalisation, d'expiration et d'annulation de Firma.dev. Voir e-mails de signature électronique et liens de signature en marque blanche.

Après la signature

• Une page de confirmation avec vos propres titre, message et redirection HTTPS, abordée dans la section personnalisation de la page de confirmation.

• Sceaux d'organisation avec le tampon de votre entreprise sur les PDF finalisés.

Par client

• Avec les Espaces de travail client, chaque paramètre prenant en charge le niveau de l'espace de travail peut différer d'un client à l'autre.

Les libellés et la visibilité se combinent, permettant à un espace de travail de renommer Refuser de signer en « Demander des modifications » tandis qu'un autre espace de travail le masque complètement. Le guide complet de l'API de signature électronique en marque blanche passe en revue chaque commande en détail, et la page des fonctionnalités de signature électronique en marque blanche en présente une vue d'ensemble. Tout cela est proposé au même tarif que le reste sur la page des tarifs de Firma.dev : 0,049 € par enveloppe (~0,05 $ USD), paiement à l'usage, sans minimum mensuel ni frais par utilisateur.

Quatre niveaux, le plus spécifique l'emporte

Chaque bouton peut être configuré à quatre niveaux : entreprise, espace de travail, modèle et demande de signature. Firma.dev lit d'abord la valeur propre à la demande de signature. Lorsque celle-ci est null, la valeur de l'espace de travail s'applique, et lorsque l'espace de travail est également null, la valeur de l'entreprise s'applique. La valeur par défaut de l'entreprise étant true, rien ne change tant que vous ne la modifiez pas. Deux règles de synchronisation s'appliquent une fois en production.

Les modèles sont copiés à la création

Une demande de signature créée à partir d'un modèle copie les valeurs du modèle au moment de sa création. Une valeur transmise dans les settings de l'appel de création remplace le modèle, et une valeur null se rabat sur l'espace de travail. Modifier le modèle ultérieurement n'affecte pas les demandes déjà créées à partir de celui-ci.

Les modifications de l'espace de travail et de l'entreprise s'appliquent aux demandes déjà envoyées

Toute demande de signature dont la valeur propre est null prend en compte une modification de l'espace de travail ou de l'entreprise, y compris les demandes déjà envoyées pour signature. Basculez allow_decline sur false sur un espace de travail actif, et chaque demande en cours sans valeur spécifique perdra également le bouton Refuser... vérifiez donc au préalable les demandes en circulation.

Où le trouver dans le tableau de bord

• Entreprise : Paramètres > Paramètres de l'entreprise, sous Boutons de la page de signature. Deux commutateurs définissent la valeur par défaut pour chaque espace de travail.

• Espace de travail : l'onglet Paramètres de l'espace de travail, sous Boutons de la page de signature. Choisissez Afficher, Masquer ou Utiliser la valeur par défaut de l'entreprise, et la modification est enregistrée immédiatement.

• Modèle et demande de signature : l'onglet des paramètres du document dans la barre latérale de l'éditeur, avec Afficher, Masquer ou Utiliser la valeur par défaut de l'espace de travail. Une demande de signature peut être modifiée jusqu'à son envoi.

Exécutez votre propre flux de refus au sein de votre produit

Lorsqu'un signataire refuse, de nombreux produits ont besoin d'en connaître la raison. Un outil de vente souhaite l'enregistrer sur la fiche de l'opportunité, une application de prêt souhaite qu'un agent rappelle le client, et une place de marché souhaite envoyer un devis révisé. Avec allow_decline: false, Firma.dev rejette tout refus sur la demande, de sorte que le bouton Refuser dans votre propre interface devient le seul moyen pour un signataire de dire non.

Un flux type se présente comme suit :

1. Définissez allow_decline: false sur la demande de signature, son modèle ou l'espace de travail, et intégrez la page de signature dans une iframe pointant vers https://app.firma.dev/signing/{signing_request_user_id}.

2. Placez votre propre bouton Refuser à côté de l'iframe. Lorsque le signataire clique dessus, ouvrez votre propre boîte de dialogue et recueillez un motif.

3. Acheminez ce motif là où il doit aller : une note CRM, une alerte au responsable de compte, un ticket d'assistance.

4. Depuis votre backend, annulez la demande de signature en y joignant le motif.

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/SIGNING_REQUEST_ID/cancel \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Signer declined in app: pricing", "notify_signers": true}'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/SIGNING_REQUEST_ID/cancel \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Signer declined in app: pricing", "notify_signers": true}'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/SIGNING_REQUEST_ID/cancel \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Signer declined in app: pricing", "notify_signers": true}'

reason est facultatif et limité à 500 caractères. notify_signers est défini par défaut sur true, définissez-le donc sur false si votre produit envoie son propre message au signataire. L'annulation fonctionne sur une demande qui a été envoyée et qui n'est pas déjà terminée ou annulée, et renvoie 409 dans le cas contraire. La même règle s'applique aux approbateurs, car un refus masqué concerne chaque participant à la demande.

Firma.dev est conforme à l'ESIGN Act, à l'UETA, à eIDAS (SES et AES) et au UK eIDAS, et les signatures sont juridiquement contraignantes dans plus de 55 pays, quels que soient les boutons affichés.

Formulaires à signature unique

Un formulaire d'une page avec une seule signature n'a aucune raison d'être repris plus tard... masquez Enregistrer et terminer plus tard sur ce modèle et le signataire aura un bouton de moins à gérer.

Un seul flux de travail, des règles différentes

Conservez le refus activé par défaut au niveau de l'entreprise et désactivez-le sur un modèle spécifique... par exemple, pour un accusé de réception de politique interne où le refus ne fait pas partie du processus. Tous les autres modèles conservent le bouton.

Configurez-le avec l'API

Les quatre niveaux acceptent les deux mêmes clés. La valeur par défaut de l'entreprise accepte uniquement true ou false :

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/company/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": true, "show_save_for_later": true}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/company/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": true, "show_save_for_later": true}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/company/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": true, "show_save_for_later": true}'

Une surcharge au niveau de l'espace de travail accepte null pour se rabattre sur la valeur de l'entreprise :

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/workspace/WORKSPACE_ID/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": false, "show_save_for_later": null}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/workspace/WORKSPACE_ID/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": false, "show_save_for_later": null}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/workspace/WORKSPACE_ID/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": false, "show_save_for_later": null}'

Par demande, les clés sont placées dans settings lors de l'appel POST /signing-requests ou POST /signing-requests/create-and-send. Cet exemple utilise les destinataires du modèle car aucun n'est transmis :

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order form - Acme",
    "template_id": "TEMPLATE_ID",
    "settings": {"allow_decline": false, "show_save_for_later": false}
  }'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order form - Acme",
    "template_id": "TEMPLATE_ID",
    "settings": {"allow_decline": false, "show_save_for_later": false}
  }'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order form - Acme",
    "template_id": "TEMPLATE_ID",
    "settings": {"allow_decline": false, "show_save_for_later": false}
  }'

Sur PUT /signing-requests/{id}, le même objet se trouve sous signing_request_properties.settings, et sur PUT /templates/{id} sous template_properties.settings. POST /templates et les routes PATCH acceptent un champ settings de premier niveau. Toute valeur autre que true, false ou null renvoie 400 VALIDATION_ERROR en indiquant la clé, et rien n'est enregistré. Le tableau complet des routes est disponible dans le journal des modifications de l'API pour la v1.40.0.

Également dans la v1.40.0 : une erreur 413 explicite pour les requêtes trop volumineuses

Les corps de requête supérieurs à 6 Mio renvoient désormais 413 REQUEST_TOO_LARGE avec le corps standard error et code. Auparavant, la passerelle répondait par un 502, ce qui donnait très peu d'informations sur l'origine du problème. Pour les fichiers plus volumineux, demandez une URL de téléversement avec POST /documents, téléversez-y le fichier et transmettez document_id ou document_ids dans votre appel de création.

En résumé, la v1.40.0 vous permet de masquer Refuser de signer et Enregistrer et terminer plus tard au niveau de l'entreprise, de l'espace de travail, du modèle ou de la demande. Un refus masqué est strictement appliqué, et le point de terminaison d'annulation offre à votre propre flux de refus une manière propre de clôturer la demande. Et tout cela vient s'ajouter au logo, aux couleurs, aux libellés, aux conditions pour les signataires, aux e-mails et à la page de confirmation que vous contrôlez déjà.

Commencez gratuitement avec Firma.dev, aucune carte bancaire requise.