Ce que nous avons expédié en janvier 2026

Janvier a été un mois chargé. Nous avons expédié un tas de mises à jour à Firma.dev dont nous sommes très enthousiastes, et la plupart d'entre elles proviennent directement des retours que nous avons reçus des développeurs utilisant 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 qualité de vie. D'autres débloquent de nouveaux flux de travail. Nous en sommes maintenant à la version 1.2.0, et tout est déjà en ligne.

Voici le récapitulatif.

Demandes de signature 40% plus rapides

Nous avons passé quelques semaines à creuser dans les performances et avons réussi à réduire notre latence moyenne de demande de signature de 820ms à environ 500ms. C'est une amélioration d'environ 40% à travers toute la ligne.

Les changements concernaient principalement le travail lié à l'infrastructure. Nous avons nettoyé certaines requêtes de base de données qui étaient devenues inefficaces au fil du temps, et nous avons déplacé des actifs statiques derrière AWS CloudFront pour la mise en cache en périphérie. Rien de révolutionnaire, mais le genre de travail qui s'accumule.

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

Demandes de signature unique (sans modèle requis)

Aujourd'hui, si vous vouliez envoyer un document pour signature via Firma.dev, vous deviez d'abord créer un modèle. Cela avait du sens pour les flux de travail répétitifs comme les contrats de travail ou les NDA, mais cela ajoutait des étapes inutiles pour les documents ponctuels.

Vous pouvez maintenant ignorer complètement le modèle. Téléchargez un PDF directement, définissez vos champs et destinataires en ligne, puis envoyez-le. Un seul appel API, pas besoin de créer un modèle.

Ceci est utile pour les accords ponctuels, les contrats uniques, ou toute situation où vous n'allez pas réutiliser la structure du document. Vous obtenez toujours tous les mêmes types de champs, options de signataire et de suivi. Vous n'avez simplement pas besoin de configurer un modèle d'abord.

Consultez le création de demande de signature pour obtenir des détails sur l'implémentation.

Point de terminaison de création + envoi atomique

En parlant de réduction des appels d'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.

Aujourd'hui, vous appeliez le point de terminaison de création, puis appeliez 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 vrai avantage est l'intégrité transactionnelle. Le point de terminaison valide tout avant de créer quoi que ce soit. Si quelque chose échoue lors de la validation, rien n'est créé et vous n'êtes pas facturé. Les crédits ne sont déduits que lorsque la demande de signature est créée avec succès et que les e-mails sont envoyés.

Depuis les docs : "Un seul appel API au lieu de deux requêtes séparées... Déduction de crédit atomique – ne facture que si tout réussit."

Si vous construisez des automatisations ou des flux de travail à fort volume, ce point de terminaison est plus propre et plus fiable que de chaîner deux appels ensemble.

Champs en lecture seule

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

Ceci 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 à des fins de contexte mais ne devrait pas pouvoir changer.

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

Contrôles granulaires des e-mails

Nous avons ajouté quatre nouveaux réglages qui vous donnent un contrôle précis sur les e-mails que Firma.dev envoie en votre nom :

• send_signing_email – la notification initiale "veuillez signer ce document"

• send_finish_email – la confirmation "signature complète"

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

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

Les quatre sont par défaut réglées sur true, donc les intégrations existantes fonctionnent exactement comme avant. Mais si vous souhaitez envoyer vos propres e-mails de marque à la place des nôtres, vous pouvez maintenant désactiver tout ou une partie de ces options et gérer vous-même les notifications.

Cela s'accorde bien avec les paramètres de marque blanche ci-dessous.

Ignorez les termes de Firma.dev pour un marquage complet en marque blanche

Il y a un nouveau paramètre dans votre espace de travail appelé "Exiger l'acceptation des termes." Lorsqu'il est activé (par défaut), les signataires doivent accepter les termes et conditions 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 veulent 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 termes. Firma.dev reste invisible.

Si vous empruntez cette voie, nous vous recommandons de mettre en place vos propres termes et conditions. Vous prenez la responsabilité d'informer les signataires des implications légales de leur signature, alors assurez-vous que vos propres CGU couvrent cela.

Combiné avec les contrôles des e-mails ci-dessus, vous pouvez maintenant exécuter une expérience de signature complètement marquée sans aucune interface utilisateur de Firma.dev apparaissant pour vos utilisateurs finaux.

Nouveaux guides pour développeurs

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

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

Guide des limites de taux – Documente tous les niveaux de limites de taux (200 requêtes/min pour les lectures, 120/min pour les écritures, etc.). Note importante ici : les limites de taux sont par espace de travail, et vous pouvez avoir un nombre illimité d'espaces de travail sur votre compte. Cela vous donne une évolutivité horizontale effectivement 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 un très fort volume.

Guide de configuration complet – Un guide complet de bout en bout depuis la création de compte jusqu'à 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 l'endroit pour commencer.

Versioning complet de l'API

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

En résumé : nous nous engageons à ne pas casser votre intégration. Depuis le guide de versioning : "Les changements perturbateurs ne sont introduits que dans les incréments de versions majeures... Les changements non perturbateurs tels que de nouveaux champs optionnels ou de nouveaux points de terminaison ne nécessitent pas une nouvelle version."

Lorsque nous finirons par sortir une v2, l'ancienne version ne disparaîtra pas simplement. Vous recevrez des avertissements de dépréciation dans les en-têtes de réponse pendant au moins six mois avant que quoi que ce soit ne soit supprimé. 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 APIs, vous saurez à quoi vous attendre.

Pour l'instant, la v1 est active sans dépréciation prévue. Tout ce que nous avons livré ce mois-ci est additif, donc votre intégration existante continue de fonctionner sans changements.

Conclusion

C'était janvier. Beaucoup d'améliorations petites à moyennes qui s'additionnent pour former une API plus capable et plus flexible.

Tarification n'a pas changé. C'est toujours $0.029 par enveloppe, payez au fur et à mesure, sans minimums. Si vous n'avez pas encore essayé Firma.dev, vous obtenez gratuitement 25 enveloppes pour tester.

Nous allons continuer à expédier. Si vous souhaitez voir quelque chose dans l'API, faites-le nous savoir.

Commencez gratuitement – aucune carte de crédit requise.