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 conséquent pour mériter son propre article, mais ensemble, ils couvrent le genre de gestion interne indispensable dès que vous traitez un volume réel via l'API. Voici ce qui est disponible.

Supprimer des demandes de signature non envoyées via l'API

Vous pouvez désormais supprimer programmatiquement les projets de demandes de signature avec DELETE /signing-requests/{id}. Cela s'applique uniquement aux demandes qui n'ont pas encore été envoyées. Une fois qu'une demande est envoyée, elle reste sur le parcours d'annulation, ce qui permet de conserver l'historique d'audit intact 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 demande qui a déjà été envoyée, vous obtiendrez un code 409 plutôt qu'un échec silencieux, ce qui permet à votre code de 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 demande 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 maintenir vos enregistrements synchronisés sans avoir à effectuer de requêtes répétées.

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

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

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

Pour les demandes où la vérification par OTP est activée, les sessions de signataire expirent désormais selon un calendrier strict. Une session prend fin après une période d'inactivité glissante de 4 heures, ou au maximum 12 heures après la dernière vérification, selon la première de ces limites. Lorsqu'une session expire, le signataire doit se réauthentifier avec 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 renvoi.

Cela concerne uniquement les requêtes pour lesquelles require_otp_verification est activé. Si vous n'utilisez pas la vérification par OTP, rien ne change pour vous. Pour les demandes 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 par-dessus.

L'intérêt réside dans la gestion des appareils partagés et publics. Si un signataire ouvre un document confidentiel sur une machine qui ne lui appartient pas et s'en éloigne, une session qui n'expire jamais représente un risque. Une période d'inactivité stricte combinée à une limite maximale restreint le temps durant lequel cette vulnérabilité reste exposée. Si vous traitez des accords exigeant une réelle confidentialité, cela renforce votre sécurité et vous aide à respecter les exigences de contrôle d'accès prévues par des cadres de conformité tels que HIPAA et SOC 2.

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

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

Auparavant, la suppression d'un domaine d'envoi d'e-mails personnalisé était bloquée lorsqu'il s'agissait de votre domaine principal ou unique. Cette restriction a été levée. L'action DELETE sur les points de terminaison de domaine de l'entreprise ou de l'espace de travail fonctionne désormais, que le domaine soit principal ou non.

Après sa suppression, l'e-mail sortant bascule sur l'expéditeur par défaut de l'entreprise, puis sur celui de la plateforme si aucun expéditeur d'entreprise n'est configuré. Pour migrer proprement vers un nouveau domaine personnalisé, vous ajoutez le nouveau, le vérifiez et le définissez comme 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 restant.

Il s'agit d'un changement mineur, mais il élimine un véritable point de friction pour quiconque migre ses domaines. La migration de domaine ne devrait pas nécessiter l'ouverture d'un ticket d'assistance, et c'est désormais le cas.

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

Démarrer

Ces trois changements sont désormais opérationnels 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émarrez gratuitement avec Firma.dev, sans carte de crédit requise. Paiement à l'usage à $0.049 par enveloppe (5¢ USD), sans minimum mensuel, sans contrat.