Ce que nous avons expédié en janvier 2026

Janvier a été un mois bien rempli. Nous avons déployé un ensemble de mises à jour sur Firma.dev qui nous enthousiasment beaucoup, et la plupart d'entre elles proviennent directement des retours que nous avons reçus des développeurs qui construisent sur l'API.

Le thème de ce mois-ci était de rendre l'API plus rapide, plus flexible et plus facile à intégrer. Certains de ces changements sont de petites améliorations de la qualité de vie. D'autres ouvrent la voie à de tout nouveaux flux de travail. Nous en sommes maintenant à la version 1.2.0, et tout ce qui est présenté ici est disponible dès aujourd'hui.

Voici le récapitulatif.

Demandes de signature 40 % plus rapides

Nous avons passé quelques semaines à analyser les performances et avons réussi à réduire la latence moyenne de nos demandes de signature de 820 ms à environ 500 ms. Cela représente une amélioration d'environ 40 % sur l'ensemble de la plateforme.

Les changements concernaient principalement l'infrastructure. Nous avons optimisé certaines requêtes de base de données qui étaient devenues inefficaces avec le temps, et nous avons déplacé les ressources statiques derrière AWS CloudFront pour la mise en cache en périphérie (edge caching). Rien de révolutionnaire, mais c'est le genre de travail qui s'accumule de manière bénéfique.

Si vous intégrez des signatures dans votre produit, cela a plus d'importance qu'il n'y paraît. Une latence de 300 ms ne semble pas énorme, mais c'est la différence entre un parcours de signature qui semble instantané et un autre qui semble lent. Des réponses plus rapides signifient moins de parcours abandonnés et moins de frictions pour vos utilisateurs.

Demandes de signature uniques (sans modèle requis)

Auparavant, si vous vouliez envoyer un document pour signature via Firma.dev, vous deviez d'abord créer un modèle. Cela faisait sens pour des flux de travail répétitifs comme les contrats de travail ou les accords de confidentialité (NDA), mais cela ajoutait des étapes inutiles pour les documents uniques.

Désormais, vous pouvez vous passer complètement de modèle. Téléversez directement un PDF, définissez vos champs et vos destinataires en ligne, et envoyez-le. Un seul appel API, aucune création de modèle requise.

C'est très utile pour les accords ad hoc, les contrats uniques ou toute situation où vous n'allez pas réutiliser la structure du document. Vous bénéficiez toujours des mêmes types de champs, options de signataire et suivi. Vous n'avez simplement pas besoin de configurer un modèle au préalable.

Consultez le point de terminaison de création de demande de signature pour les détails d'implémentation.

Point de terminaison atomique de Création + Envoi

En parlant de réduction des appels API : nous avons ajouté un nouveau point de terminaison atomique qui vous permet de créer et d'envoyer une demande de signature en un seul appel.

Auparavant, vous deviez appeler le point de terminaison de création, puis le point de terminaison d'envoi. Deux requêtes, deux allers-retours. Le nouveau point de terminaison /signing-requests/create-and-send combine les deux en un seul.

Mais le véritable avantage est l'intégrité transactionnelle. Le point de terminaison valide tout avant de créer quoi que ce soit. Si un élément échoue à la validation, rien n'est créé et vous n'êtes pas facturé. Les crédits ne sont déduits qu'une fois la demande de signature créée avec succès et les e-mails envoyés.

Extrait de la documentation : « Un seul appel API au lieu de deux requêtes distinctes... Déduction atomique des crédits – ne facture que si tout réussit. »

Si vous créez des automatisations ou des flux de travail à fort volume, ce point de terminaison est plus propre et plus fiable que d'enchaîner deux appels.

Champs en lecture seule

Vous pouvez désormais marquer des champs comme étant en lecture seule lors de la création ou de la mise à jour d'une demande de signature. Il s'agit de champs qui apparaissent sur le document avec des valeurs pré-remplies, mais que le signataire ne peut pas modifier.

C'est utile pour des éléments tels que les montants des contrats, les numéros de référence, les totaux calculés ou les identifiants d'employés. Tout ce que le signataire doit voir pour le contexte mais ne doit pas pouvoir modifier.

Vous trouverez la propriété read_only dans le point de terminaison de mise à jour complète. Définissez-la sur true sur n'importe quel champ de texte, et il deviendra visible mais non modifiable.

Contrôles précis des e-mails

Nous avons ajouté quatre nouveaux paramètres qui vous permettent de contrôler précisément quels e-mails Firma.dev envoie en votre nom :

• send_signing_email – la notification initiale « merci de signer ce document »

• send_finish_email – la confirmation de « signature terminée »

• send_expiration_email – le rappel lorsqu'une demande est sur le point d'expirer

• send_cancellation_email – la notification lorsqu'une demande est annulée

Ces quatre paramètres sont définis sur true par défaut, de sorte que les intégrations existantes fonctionnent exactement comme avant. Mais si vous souhaitez envoyer vos propres e-mails personnalisés à votre marque plutôt que les nôtres, vous pouvez désormais désactiver tout ou partie de ces paramètres et gérer les notifications vous-même.

Cela s'associe parfaitement avec les paramètres de marque blanche ci-dessous.

Passer les conditions de Firma.dev pour une marque blanche complète

Il y a un nouveau paramètre dans votre espace de travail appelé « Exiger l'acceptation des conditions ». Lorsqu'il est activé (par défaut), les signataires doivent accepter les conditions générales de Firma.dev avant de signer. Lorsque vous le désactivez, cette étape disparaît complètement.

Ceci est conçu pour les équipes qui souhaitent une expérience de signature entièrement en marque blanche. Vos signataires voient votre marque, vos e-mails (si vous avez désactivé les nôtres) et vos conditions. Firma.dev reste invisible.

Si vous choisissez cette option, nous vous recommandons d'avoir vos propres conditions générales en place. Vous assumez la responsabilité d'informer les signataires des implications juridiques de leur signature, assurez-vous donc que vos propres conditions générales couvrent cela.

Combiné avec les contrôles d'e-mails ci-dessus, vous pouvez désormais proposer une expérience de signature entièrement personnalisée sans qu'aucune interface utilisateur de Firma.dev n'apparaisse pour vos utilisateurs finaux.

Nouveaux guides pour les développeurs

Nous avons réécrit une grande partie de notre documentation ce mois-ci. Trois nouveaux guides sont disponibles :

Guide d'authentification – Couvre l'authentification par clé API pour les requêtes de serveur à serveur, ainsi que les jetons JWT pour intégrer les éditeurs de modèles et de demandes de signature dans votre application. Comprend également le nouveau flux de rotation des clés API avec des périodes de grâce de 24 heures.

Guide des limites de taux – Documente tous les niveaux de limite de taux (200 requêtes/min pour les lectures, 120/min pour les écritures, et ainsi de suite). Note importante ici : les limites de taux s'appliquent par espace de travail, et vous pouvez avoir un nombre illimité d'espaces de travail sur votre compte. Cela vous offre une évolutivité horizontale pratiquement illimitée. Si vous avez besoin de limites encore plus élevées pour un cas d'utilisation spécifique, contactez le support et nous pourrons les augmenter, mais les valeurs par défaut sont déjà conçues pour des volumes très élevés.

Guide de configuration complet – Un guide complet de bout en bout, de la création du compte à la signature intégrée. Couvre les espaces de travail, les modèles, les demandes de signature, les éditeurs intégrés, les webhooks et la gestion des crédits. Si vous débutez, c'est par ici qu'il faut commencer.

Gestion complète des versions de l'API

Nous avons introduit un système formel de gestion des versions ce mois-ci. L'API utilise désormais un versionnage basé sur les en-têtes via l'en-tête X-API-Version, et nous en sommes actuellement à la v1.2.0.

En résumé : nous nous engageons à ne pas casser votre intégration. D'après le guide de versionnage : « Les changements de rupture ne sont introduits que dans les incréments de version majeure... Les changements mineurs qui ne cassent pas la compatibilité, comme les nouveaux champs facultatifs ou les nouveaux points de terminaison, ne nécessitent pas de nouvelle version. »

Lorsque nous sortirons une v2, l'ancienne version ne disparaîtra pas d'un coup. Vous recevrez des avertissements d'obsolescence dans les en-têtes de réponse pendant au moins six mois avant que quoi que ce soit ne soit retiré. Les en-têtes suivent la RFC 8594, donc si vous vérifiez déjà les en-têtes Deprecation et Sunset dans d'autres API, vous saurez à quoi vous attendre.

Pour l'instant, la v1 est active et aucune obsolescence n'est planifiée. Tout ce que nous avons déployé ce mois-ci est additif, donc votre intégration existante continue de fonctionner sans modifications.

En conclusion

Voilà pour janvier. Beaucoup d'améliorations mineures à moyennes qui s'additionnent pour former une API plus performante et plus flexible.

Les tarifs n'ont pas changé. C'est toujours €0,049 par enveloppe, au paiement à l'usage, sans minimum. Si vous n'avez pas encore essayé Firma.dev, vous pouvez tester gratuitement avec de vrais documents, sans limites, et ne payer que lorsque vous passez en production.

Nous allons continuer à déployer des nouveautés. S'il y a quelque chose que vous aimeriez voir dans l'API, faites-le nous savoir.

Commencer gratuitement – aucune carte de crédit requise.