Ce que nous avons expédié en janvier 2026

Janvier a été un mois chargé. Nous avons expédié un tas de mises à jour pour Firma.dev qui nous enthousiasment beaucoup, et la plupart d'entre elles proviennent directement des retours que nous avons reçus des développeurs construisant 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 débloquent des flux de travail entièrement nouveaux. Nous en sommes maintenant à la version 1.2.0, et tout cela est en ligne aujourd'hui.

Voici le récapitulatif.

40 % de demandes de signature plus rapides

Nous avons passé quelques semaines à creuser dans la performance et avons réussi à réduire notre latence moyenne de demande de signature de 820 ms à environ 500 ms. C'est environ une amélioration de 40 % dans l'ensemble.

Les changements étaient principalement des travaux d'infrastructure. Nous avons nettoyé certaines requêtes de base de données qui étaient devenues inefficaces avec le temps, et nous avons placé des ressources 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 compte plus qu'il n'y paraît. 300 ms de latence ne semblent pas être 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 ponctuelles (pas de 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 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.

Maintenant, vous pouvez complètement ignorer le modèle. Téléchargez un PDF directement, définissez vos champs et destinataires en ligne, et envoyez-le. Une seule requête API, pas besoin de créer de modèle.

Cela est utile pour des accords ponctuels, des 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 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 de mise en œuvre.

Point de terminaison de création + envoi atomique

En parlant de réduire les 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 appeliez 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 quelque chose échoue à la validation, rien n'est créé et vous n'êtes pas facturé. Les crédits sont déduits uniquement après la création réussie de la demande de signature et l'envoi des emails.

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 à haut volume, ce point de terminaison est plus propre et plus fiable que de chaîner deux appels ensemble.

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. Ce sont des 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 comme les montants de contrat, les numéros de référence, les totaux calculés, ou les IDs d'employé. Tout ce que le signataire doit voir pour le contexte mais ne devrait pas pouvoir changer.

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

Contrôles granulaires des emails

Nous avons ajouté quatre nouveaux paramètres qui vous donnent un contrôle précis sur les emails que Firma.dev envoie en votre nom :

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

• send_finish_email – la confirmation de "signature complète"

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

• send_cancellation_email – la notification quand une demande est annulée

Les quatre sont par défaut sur true, donc les intégrations existantes fonctionnent exactement comme avant. Mais si vous voulez envoyer vos propres emails de marque plutôt que les nôtres, vous pouvez maintenant désactiver tout ou partie de ces options et gérer les notifications vous-même.

Cela se marie bien avec les paramètres en marque blanche ci-dessous.

Passer les conditions de Firma.dev pour un étiquetage blanc complet

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 entièrement.

Cela est conçu pour les équipes qui veulent une expérience de signature complètement en marque blanche. Vos signataires voient votre image de marque, vos emails (si vous avez désactivé les nôtres), et vos conditions. Firma.dev reste invisible.

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

Combiné avec les contrôles de courrier électronique ci-dessus, vous pouvez maintenant proposer une expérience de signature complètement marquée sans aucun affichage de l'interface utilisateur de Firma.dev pour vos utilisateurs finaux.

Nouveaux guides développeurs

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

Guide d'authentification – Couvre l'authentification par clé API pour les requêtes de serveur à serveur, ainsi que les jetons JWT pour intégrer le modèle et les éditeurs de demande de signature dans votre application. Inclut également le nouveau flux de rotation de clé 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, etc.). Note importante ici : les limites de taux sont par espace de travail, et vous pouvez avoir des espaces de travail illimités 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 pouvons les augmenter, mais les valeurs par défaut sont déjà construites pour un volume très élevé.

Guide de configuration complète – Un parcours 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 commencez tout juste, c'est l'endroit où commencer.

Mise à jour complète de la version de l'API

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

La version courte : nous nous engageons à ne pas casser votre intégration. Du guide de versionnement : "Les changements rétrocompatibles ne sont introduits que dans les incréments de version majeure... Les changements non rétrocompatibles tels que de nouveaux champs optionnels ou de nouveaux points de terminaison ne nécessitent pas de nouvelle version."

Lorsque nous publierons finalement 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 obsolète. 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 expédié ce mois-ci est additionnel, donc votre intégration existante continue de fonctionner sans changements.

Conclusion

C'est janvier. Beaucoup d'améliorations petites à moyennes qui s'additionnent pour donner une API plus capable, plus flexible.

Tarification n'a pas changé. C'est toujours $0.029 par enveloppe, paiement à l'utilisation, pas de minimum. Si vous n'avez pas encore essayé Firma.dev, vous obtenez 25 enveloppes gratuites pour tester.

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

Commencez gratuitement – pas de carte de crédit requise.