Produkt-Updates, Juni 2026: Entwurfsbereinigung, Sitzungssicherheit und Domainverwaltung

In diesem Monat wurden drei Änderungen eingeführt, die einen gemeinsamen Nenner haben: mehr operative Kontrolle über die Anfragen, Sitzungen und Domains, die Ihre Integration verwaltet. Keine davon ist groß genug für einen eigenen Beitrag, aber zusammen decken sie die Art von Verwaltungsaufgaben ab, die wichtig werden, wenn Sie ein signifikantes Volumen über die API abwickeln. Hier ist, was neu ist.

Löschen von ungesendeten Signaturanfragen über die API

Sie können Entwürfe von Signaturanfragen jetzt programmatisch mit DELETE /signing-requests/{id} löschen. Dies gilt nur für Anfragen, die noch nicht gesendet wurden. Sobald eine Anfrage gesendet wurde, bleibt sie stattdessen auf dem Stornierungspfad, wodurch das Prüfprotokoll für alles, was ein Unterzeichner eventuell bereits gesehen hat, intakt bleibt.

Ein erfolgreicher Aufruf gibt eine 200 mit der signing_request_id und einem deleted_on-Zeitstempel zurück. Wenn Sie versuchen, eine bereits gesendete Anfrage zu löschen, erhalten Sie eine 409 anstelle eines lautlosen Fehlers, sodass Ihr Code sauber zwischen Löschen und Stornieren unterscheiden kann. Eine fehlende oder unbekannte ID gibt 404 zurück.

Es gibt auch ein neues Webhook-Ereignis signing_request.deleted, das ausgelöst wird, wenn eine Anfrage über die API gelöscht wird. Wenn Sie den Signaturstatus in Ihre eigene Datenbank spiegeln, können Sie dieses abonnieren und Ihre Datensätze ohne Polling synchron halten.

Der offensichtliche Anwendungsfall ist die Bereinigung. Wenn Ihre Integration Entwürfe im Rahmen eines Erstellungs- und Überprüfungsablaufs erstellt oder spekulativ Anfragen generiert und diejenigen verwirft, die nicht verwendet werden, müssen Sie nicht genutzte Entwürfe nicht mehr ungenutzt herumliegen lassen. Sie können sie im Rahmen desselben Ablaufs löschen, mit dem sie erstellt wurden.

Dies wurde in API v1.22.0 veröffentlicht.

Striktere Ablauffristen für Unterzeichnersitzungen bei OTP-geschützten Anfragen

Bei Anfragen, für die die OTP-Verifizierung aktiviert ist, laufen Unterzeichnersitzungen nun nach einem festen Zeitplan ab. Eine Sitzung endet nach einem rollierenden 4-stündigen Inaktivitätsfenster oder 12 Stunden nach der letzten Verifizierung als absolute Obergrenze, je nachdem, was zuerst eintritt. Wenn eine Sitzung abläuft, verifiziert sich der Unterzeichner erneut mit einem neuen 6-stelligen Code. Dieser Code ist 10 Minuten lang gültig, erlaubt 5 Versuche und hat eine 60-sekündige Abkühlzeit für den erneuten Versand.

Dies betrifft nur Anfragen, bei denen require_otp_verification aktiviert ist. Wenn Sie keine OTP-Verifizierung nutzen, ändert sich für Sie nichts. Für Anfragen, die diese nutzen, ist keine Aktion des Absenders erforderlich, und bestehende Signatur-Links funktionieren weiterhin. Das neue Ablaufverhalten wird einfach zusätzlich angewendet.

Der Grund, warum dies wichtig ist, sind gemeinsam genutzte und öffentliche Geräte. Wenn ein Unterzeichner ein vertrauliches Dokument auf einem fremden Computer öffnet und sich entfernt, stellt eine Sitzung, die niemals abläuft, ein Sicherheitsrisiko dar. Ein festes Inaktivitätsfenster plus eine absolute Obergrenze schränkt die Dauer dieses Fensters ein. Wenn Sie Vereinbarungen bearbeiten, die echte Vertraulichkeitsanforderungen mit sich bringen, stärkt dies Ihre Sicherheitsposition und hilft Ihnen, die Anforderungen an die Zugriffskontrolle zu erfüllen, die für Frameworks wie HIPAA und SOC 2 wichtig sind.

Details finden Sie im Eintrag zu den Plattform-Updates vom 29. Mai, wobei die zugrunde liegende OTP-Einstellung ab API v1.09.00 dokumentiert ist.

Löschen einer primären oder einzigen Domain für den E-Mail-Versand

Das Löschen einer benutzerdefinierten E-Mail-Versanddomain war bisher gesperrt, wenn es sich um Ihre primäre oder einzige Domain handelte. Diese Einschränkung ist nun aufgehoben. DELETE auf den Domain-Endpunkten des Unternehmens oder Arbeitsbereichs funktioniert jetzt unabhängig davon, ob die Domain primär ist.

Nach dem Löschen greift der E-Mail-Versand auf den Standardabsender des Unternehmens zurück und anschließend auf den Plattform-Standard, falls kein Unternehmensabsender eingerichtet ist. Um sauber zu einer neuen benutzerdefinierten Domain zu wechseln, fügen Sie die neue hinzu, verifizieren sie und legen sie als primär fest. Sie müssen eine veraltete Domain nicht mehr behalten, nur weil die API das Entfernen der letzten nicht zuließ.

Dies ist eine kleine Änderung, aber sie beseitigt ein echtes Problem für alle, die Domains migrieren. Eine Domain-Migration sollte kein Support-Ticket erfordern, und jetzt tut sie es auch nicht mehr.

Dies wurde in API v1.22.1 veröffentlicht.

Erste Schritte

Alle drei Änderungen sind ab sofort in der API aktiv. Vollständige Details zu Anfragen und Antworten finden Sie im API-Änderungsprotokoll.

Starten Sie kostenlos mit Firma.dev, keine Kreditkarte erforderlich. Pay-as-you-go für $0.029 pro Umschlag (2.9¢ USD), ohne monatliche Mindestumsätze, ohne Verträge.