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 faire l'objet d'un article dédié, mais ensemble, ils couvrent le genre de maintenance qui compte dès que vous avez un volume réel transitant par l'API. Voici ce qui est arrivé.

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

Vous pouvez désormais supprimer les brouillons de demandes de signature de manière programmatique 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 la piste d'audit intacte pour tout ce qu'un signataire a pu déjà consulter.

Un appel réussi renvoie un code 200 avec le signing_request_id et un horodatage deleted_on. Si vous essayez de supprimer une demande 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 ID 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 périodiques.

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 demandes de manière spéculative et rejette celles qui ne sont pas utilisées, vous n'avez plus à laisser traîner des brouillons abandonnés. Vous pouvez les supprimer dans le cadre du flux même qui les a créés.

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

Expiration renforcée des sessions de signataire sur les demandes protégées par OTP

Pour les demandes 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 fenêtre d'inactivité glissante de 4 heures, ou 12 heures après la dernière vérification comme limite absolue, selon la première éventualité. Lorsqu'une session expire, le signataire se réauthentifie avec un nouveau code à 6 chiffres. Ce code est valide pendant 10 minutes, permet 5 tentatives et possède un délai de rétractation de 60 secondes avant renvoi.

Cela ne concerne que les demandes 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 en plus.

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'en éloigne, une session qui n'expire jamais représente un risque. Une fenêtre d'inactivité stricte couplée à une limite absolue restreint la durée d'ouverture de cette fenêtre. Si vous gérez des accords qui impliquent de réelles exigences de confidentialité, cela renforce votre sécurité et vous aide à respecter les exigences de contrôle d'accès auxquelles des cadres comme HIPAA et SOC 2 sont attentifs.

Les détails figurent dans l'entrée des mises à jour de la plateforme du 29 mai, le paramètre OTP sous-jacent étant documenté à partir de l'API v1.09.00.

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 disparu. La requête 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'envoi d'e-mails sortants se rabat 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 passer proprement à 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.

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

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

Commencer

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

Commencez gratuitement avec Firma.dev, sans carte de crédit requise. Paiement à l'usage à 0,049 € par enveloppe (~5¢ USD), sans minimum mensuel, sans contrat.