Mises à jour des produits, juin 2026 : Nettoyage des brouillons, sécurité des sessions et gestion des domaines

Trois changements ont été déployés ce mois-ci avec un fil conducteur commun : un meilleur contrôle opérationnel sur les requêtes, les sessions et les domaines gérés par votre intégration. Aucun d'entre eux n'est assez important pour faire l'objet de son propre article, mais ensemble, ils couvrent le genre de gestion interne qui compte dès lors que vous avez un volume réel transitant par l'API. Voici ce qui est arrivé.

Supprimer les requêtes de signature non envoyées via l'API

Vous pouvez désormais supprimer les brouillons de requêtes de signature par programmation avec DELETE /signing-requests/{id}. Cela s'applique uniquement aux requêtes qui n'ont pas encore été envoyées. Une fois qu'une requête est envoyée, elle reste sur le parcours d'annulation, ce qui permet de conserver intacte la piste d'audit pour tout ce qu'un signataire aurait déjà pu voir.

Un appel réussi renvoie un code 200 avec l'identifiant signing_request_id et un horodatage deleted_on. Si vous tentez de supprimer une requête qui a déjà été envoyée, vous obtenez un code 409 plutôt qu'un échec silencieux, afin que votre code puisse s'orienter proprement entre la suppression et l'annulation. Un identifiant manquant ou inconnu renvoie un code 404.

Il existe également un nouvel événement de webhook signing_request.deleted qui se déclenche chaque fois qu'une requête est supprimée via l'API. Si vous répliquez l'état des signatures dans votre propre base de données, vous pouvez vous y abonner et synchroniser vos enregistrements sans faire de requêtes régulières de suivi (polling).

Le cas d'usage évident est le nettoyage. Si votre intégration crée des brouillons dans le cadre d'un flux de création puis de révision, ou génère des requêtes de manière spéculative et rejette celles qui ne sont pas utilisées, vous n'avez plus besoin de laisser traîner des brouillons abandonnés. Vous pouvez les supprimer dans le cadre de ce même flux qui les a créés.

Cette fonctionnalité a été déployée avec l'API v1.22.0.

Expiration plus stricte des sessions de signature sur les requêtes protégées par OTP

Pour les requêtes pour lesquelles la vérification par OTP est activée, les sessions des signataires expirent désormais selon un calendrier strict. Une session se termine après une période d'inactivité glissante de 4 heures, ou 12 heures maximum après la dernière vérification, selon la première de ces échéances. Lorsqu'une session expire, le signataire s'identifie à nouveau à l'aide d'un nouveau code à 6 chiffres. Ce code est valide pendant 10 minutes, autorise 5 tentatives et comporte un délai d'attente de 60 secondes avant d'être renvoyé.

Cela ne concerne que les requêtes pour lesquelles l'option require_otp_verification est activée. Si vous n'utilisez pas la vérification par OTP, rien ne change pour vous. Pour les requêtes qui l'utilisent, aucune action de l'expéditeur n'est requise et les liens de signature existants continuent de fonctionner. Le nouveau comportement d'expiration s'applique simplement en complément.

L'importance de cette mesure réside dans l'utilisation d'appareils partagés et publics. Si un signataire ouvre un document confidentiel sur une machine qui ne lui appartient pas et s'éloigne, une session qui n'expire jamais représente un risque. Une période d'inactivité stricte combinée à une limite maximale restreint la durée d'ouverture de cette fenêtre. Si vous gérez des accords impliquant de réelles attentes en matière de confidentialité, cela renforce votre sécurité et vous aide à vous conformer aux exigences de contrôle d'accès requises par les frameworks tels que HIPAA et SOC 2.

Les détails figurent dans la note sur les mises à jour de la plateforme du 29 mai, et le paramètre OTP sous-jacent est documenté depuis l'API v1.09.00.

Supprimer un domaine d'envoi d'e-mails principal ou unique

Auparavant, la suppression d'un domaine personnalisé d'envoi d'e-mails était bloquée lorsqu'il s'agissait de votre domaine principal ou unique. Cette restriction a disparu. La requête DELETE sur les endpoints de domaine de l'entreprise ou de l'espace de travail fonctionne désormais, que le domaine soit principal ou non.

Une fois supprimé, l'expéditeur des e-mails sortants redevient l'expéditeur par défaut de l'entreprise, puis l'expéditeur par défaut de la plateforme si aucun expéditeur d'entreprise n'est configuré. Pour passer proprement à un nouveau domaine personnalisé, vous ajoutez le nouveau domaine, vous le vérifiez et vous le définissez comme domaine principal. Vous n'êtes plus obligé de conserver un domaine obsolète simplement parce que l'API ne vous permettait pas de supprimer le dernier.

Il s'agit d'un changement mineur, mais il élimine un véritable point de friction pour tous ceux qui migrent des domaines. La migration de domaine ne devrait pas nécessiter l'ouverture d'un ticket de support, et c'est désormais le cas.

Cette fonctionnalité a été déployée avec l'API v1.22.1.

Commencer

Ces trois modifications sont désormais actives dans l'API. Tous les détails concernant les requêtes et les réponses figurent dans le journal des modifications de l'API.

Débutez gratuitement avec Firma.dev, sans carte de crédit requise. Payez à l'utilisation à 0,029 $ par enveloppe (2,9 ¢ USD), sans minimum mensuel ni contrat.