Firma.dev API v1.6, v1.7 et v1.8 : Divisez les PDF, signatures dessinées à la main et modèles d'e-mails personnalisés

Trois versions API ont été livrées depuis v1.5, et toutes les trois sont des mises à jour non perturbatrices. Voici les nouveautés et comment les utiliser.

v1.6.0 : Téléchargements de PDF divisés et nettoyage des types de champs

Publié le 12 février 2026

La fonctionnalité la plus demandée dans la v1.6 est les téléchargements de PDF divisés. Auparavant, lorsqu'une demande de signature était terminée, vous obteniez un PDF combiné qui incluait à la fois le document signé et le certificat de traçabilité. Maintenant, vous pouvez les télécharger séparément.

Deux nouveaux champs sont disponibles sur les demandes de signature complétées :

{
  "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 lien frais, il suffit de récupérer à nouveau la demande de signature. Cela est particulièrement utile si vous devez stocker le document signé dans un système et la traçabilité dans un autre, ou si vos utilisateurs finaux ont seulement besoin du PDF signé sans les pages de certificat ajoutées.

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

Journal complet des modifications 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 exactement 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
  }
}

Une fois activé, l'interface de signature supprime toute option de signature tapée ou basée sur une police. Les signataires doivent dessiner leur signature manuellement. Ceci est utile pour les industries fortement réglementées comme la santé et les services financiers où les régulateurs ou les auditeurs attendent spécifiquement des signatures manuscrites.

Le paramètre est par défaut à 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 compatibles rétroactivement au schéma SigningRequest. Ce sont des versions basées sur des entiers (0/1) des paramètres booléens, conçues pour les intégrations plus anciennes qui attendent ce format. Si vous créez de nouvelles applications, restez avec l'objet settings. Les champs hérités sont là pour les équipes en migration depuis de vieux systèmes.

Journal complet des modifications de la v1.7

v1.8.0 : API des modèles d'e-mails et support de langue

Publié le 3 mars 2026

La v1.8 est la plus importante des trois. La fonctionnalité phare est l'API des modèles d'e-mails, qui vous donne un contrôle total sur les e-mails de notification que Firma.dev envoie pendant le processus de signature.

Vous pouvez personnaliser les modèles pour cinq types d'e-mails : signing_invite, next_signer, signing_expired, signing_cancelled et signing_declined. Les modèles supportent les 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 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 pour chaque Espace de Travail Client dans des scénarios de marque blanche où chacun de vos clients a besoin de ses propres e-mails de marque.

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

Améliorations du schéma

La v1.8 a également expédié plusieurs améliorations du schéma qui valent la peine d'être connues :

Le schéma Template inclut maintenant les destinataires recipients, les champs fields, les paramètres settings, le nombre de pages page_count, et le nombre d'heures d'expiration expiration_hours lorsque vous récupérez un seul modèle. Cela signifie moins d'appels d'API pour avoir une vue complète de la configuration d'un modèle.

Les réponses de demande 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 défaillances sont particulièrement utiles pour la surveillance. Si un webhook commence à échouer, vous pouvez désormais voir combien de défaillances consécutives se sont produites et si Firma.dev l'a désactivé automatiquement.

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

Journal complet des modifications de la v1.8

Mise à niveau

Les trois versions sont entièrement compatibles avec les versions antérieures. Aucune modification perturbatrice, aucune étape de migration requise. Vous pouvez mettre à niveau votre version API de v1.5 directement à v1.8 et tout continuera à fonctionner comme avant, avec les nouvelles fonctionnalités disponibles immédiatement.

Pour le journal complet des changements avec chaque changement de schéma et note de migration, consultez le Changement d'API dans les documents. Si vous commencez avec Firma.dev, vous pouvez obtenir votre clé API gratuitement et commencer à construire aujourd'hui.

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