Firma.dev API v1.6, v1.7 et v1.8 : Diviser des PDF, signatures manuscrites et modèles d'e-mail personnalisés

Trois versions de l'API ont été publiées depuis v1.5, et toutes les trois sont des mises à jour non perturbatrices, prêtes à l'emploi. Voici les nouveautés et comment les utiliser.

v1.6.0 : Téléchargements PDF Séparés et Nettoyage des Types de Champs

Publié le 12 février 2026

La fonctionnalité la plus demandée dans v1.6 est le téléchargement de PDF séparés. Auparavant, lorsqu'une demande de signature était terminée, vous receviez un seul PDF combiné incluant à la fois le document signé et le certificat de piste d'audit. Maintenant, vous pouvez les télécharger séparément.

Deux nouveaux champs sont disponibles sur les demandes de signature complètes :

{
  "document_only_download_url": "https://storage.example.com/document.pdf",
  "certificate_only_download_url": "https://storage.example.com/certificate.pdf"
}

{
  "document_only_download_url": "https://storage.example.com/document.pdf",
  "certificate_only_download_url": "https://storage.example.com/certificate.pdf"
}

{
  "document_only_download_url": "https://storage.example.com/document.pdf",
  "certificate_only_download_url": "https://storage.example.com/certificate.pdf"
}

Les deux URL sont pré-signées et expirent après 1 heure. Si vous avez besoin d'un nouveau lien, il vous suffit de récupérer à nouveau la demande de signature. C'est particulièrement utile si vous devez stocker le document signé dans un système et la piste d'audit dans un autre, ou si vos utilisateurs finaux n'ont besoin que du PDF signé sans les pages de certificat.

v1.6 a également nettoyé la dénomination des types de champs. L'API accepte maintenant à la fois initials et initial, ainsi que textarea et text_area, et les normalise automatiquement. Si votre intégration utilisait déjà les noms originaux, rien ne change. Si vous préférez les formes normalisées, elles fonctionnent aussi.

Changelog complet de la v1.6

v1.7.0 : Signatures Dessinées à la Main

Publié le 27 février 2026

Certains flux de travail nécessitent que les signataires dessinent physiquement leur signature plutôt que de sélectionner une option tapée ou générée par une police. La v1.7 introduit le paramètre hand_drawn_only pour imposer cela.

Ajoutez-le aux paramètres de votre demande de signature :

{
  "settings": {
    "hand_drawn_only": true,
    "use_signing_order": false,
    "allow_download": true
  }
}

{
  "settings": {
    "hand_drawn_only": true,
    "use_signing_order": false,
    "allow_download": true
  }
}

{
  "settings": {
    "hand_drawn_only": true,
    "use_signing_order": false,
    "allow_download": true
  }
}

Lorsqu'il est activé, l'interface de signature supprime complètement les options de signature tapées et basées sur des polices. Les signataires doivent dessiner leur signature à la main. Ceci est utile pour les industries fortement réglementées comme la santé et les services financiers où les régulateurs ou les auditeurs s'attendent spécifiquement à des signatures manuscrites.

Le paramètre est par défaut sur false, donc les demandes de signature existantes ne sont pas affectées.

Cette version a également ajouté des champs de paramètres hérités rétrocompatibles dans le schéma SigningRequest. Ce sont des versions basées sur des entiers (0/1) des paramètres booléens, conçues pour les anciennes intégrations qui attendent ce format. Si vous démarrez un nouveau développement, restez avec l'objet settings. Les champs hérités sont là pour les équipes qui migrent d'anciens systèmes.

Changelog complet de la v1.7

v1.8.0 : API de Modèles d'Email et Support Linguistique

Publié le 3 mars 2026

La v1.8 est la plus grande des trois. La fonctionnalité principale est l'API de Modèles d'Email, qui vous donne un contrôle total sur les emails de notification que Firma.dev envoie pendant le processus de signature.

Vous pouvez personnaliser les modèles pour cinq types d'emails : signing_invite, next_signer, signing_expired, signing_cancelled, et signing_declined. Les modèles supportent des corps HTML avec des espaces réservés comme {{signer_name}}, {{document_name}}, et {{signing_link}}.

Voici un exemple rapide :

PUT /workspace/{workspace_id}/email-templates/signing_invite
{
  "subject": "Please sign: {{document_name}}",
  "body": "<p>Hi {{signer_name}},</p><p>Please review and sign using this link: {{signing_link}}</p>"
}

PUT /workspace/{workspace_id}/email-templates/signing_invite
{
  "subject": "Please sign: {{document_name}}",
  "body": "<p>Hi {{signer_name}},</p><p>Please review and sign using this link: {{signing_link}}</p>"
}

PUT /workspace/{workspace_id}/email-templates/signing_invite
{
  "subject": "Please sign: {{document_name}}",
  "body": "<p>Hi {{signer_name}},</p><p>Please review and sign using this link: {{signing_link}}</p>"
}

Les modèles suivent une hiérarchie : les modèles au niveau de l'espace de travail remplacent les modèles au niveau de l'entreprise, qui à leur tour remplacent les modèles par défaut intégrés. Cela signifie que vous pouvez définir un modèle à l'échelle de l'entreprise puis le personnaliser par espace de travail client pour des scénarios de marque blanche où chacun de vos clients a besoin de ses propres emails de marque.

En parallèle des modèles personnalisés, v1.8 ajoute un champ language à la fois à Company et WorkspaceSettings. Réglez-le sur l'une des sept langues prises en charge (fr, es, it, pt, fr, de, el) et les modèles d'emails intégrés de Firma.dev utiliseront automatiquement cette langue. Combiné avec les remplacements au niveau de l'espace de travail, vous pouvez desservir des marchés internationaux sans gérer une infrastructure d'email distincte.

Améliorations de Schéma

La v1.8 a également apporté plusieurs améliorations de schéma qui méritent d'être connues :

Le schéma Template inclut maintenant les recipients, fields, settings, page_count, et expiration_hours en ligne lorsque vous récupérez un seul modèle. Cela signifie moins d'appels API pour obtenir une vue complète de la configuration d'un modèle.

Les réponses aux demandes de signature ont été divisées en formes spécifiques à l'endpoint (SigningRequestListItem, SigningRequestCreateResponse, SigningRequestDetail) avec des données en ligne et des champs de timestamp standardisés. Cela rend les réponses plus prévisibles et plus faciles à typer dans votre base de code.

Les webhooks ont gagné trois nouveaux champs : description, consecutive_failures, et auto_disabled_at. Les champs de suivi des échecs sont particulièrement pratiques pour la surveillance. Si un webhook commence à échouer, vous pouvez maintenant voir combien d'échecs consécutifs se sont produits et si Firma.dev l'a désactivé automatiquement.

Notez que la v1.8 a également corrigé plusieurs noms de champs dans la spécification OpenAPI pour correspondre aux réponses réelles de l'API. Si votre intégration gère déjà les champs de réponse réels (ce qui est presque certainement le cas), aucune modification n'est nécessaire.

Changelog complet de la v1.8

Mise à Niveau

Les trois versions sont entièrement rétrocompatibles. Pas de changements perturbateurs, pas d'étapes de migration requises. Vous pouvez mettre à jour votre version de l'API de v1.5 directement à v1.8 et tout continuera de fonctionner comme avant, avec les nouvelles fonctionnalités disponibles immédiatement.

Pour le changelog complet avec chaque changement de schéma et note de migration, vérifiez le Changelog de l'API dans la documentation. Si vous débutez avec Firma.dev, vous pouvez obtenir votre clé API gratuitement et commencer à développer dès aujourd'hui.

Notes de version précédentes : v1.5 | v1.3 et v1.4