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

Diesen Monat wurden drei Änderungen veröffentlicht, 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 Aufräumarbeiten ab, die wichtig werden, sobald Sie ein echtes 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, verbleibt sie stattdessen auf dem Stornierungspfad, wodurch der Audit-Trail für alles, was ein Unterzeichner möglicherweise bereits gesehen hat, intakt bleibt.

Ein erfolgreicher Aufruf gibt einen Status 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 einen Status 409 anstelle eines unbemerkt bleibenden Fehlers, sodass Ihr Code sauber zwischen Löschen und Stornieren verzweigen kann. Eine fehlende oder unbekannte ID gibt 404 zurück.

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

Der offensichtlichste Anwendungsfall ist das Aufräumen. Wenn Ihre Integration Entwürfe im Rahmen eines Erstellungs- und anschließenden Prüfablaufs erstellt oder spekulative Anfragen generiert und nicht verwendete verwirft, müssen Sie nicht mehr genutzte Entwürfe nicht mehr ungenutzt herumliegen lassen. Sie können sie im Rahmen desselben Ablaufs löschen, in dem sie erstellt wurden.

Dies wurde in API v1.22.0 eingeführt.

Strengere Sitzungsdauer für Unterzeichner bei OTP-geschützten Anfragen

Für Anfragen, bei denen die OTP-Verifizierung aktiviert ist, laufen Unterzeichnersitzungen nun nach einem festen Zeitplan ab. Eine Sitzung endet nach einem gleitenden 4-stündigen Inaktivitätsfenster oder als harte Obergrenze 12 Stunden nach der letzten Verifizierung, 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ühlweltzeit für das erneute Senden.

Dies betrifft nur Anfragen, bei denen require_otp_verification aktiviert ist. Wenn Sie keine OTP-Verifizierung verwenden, ändert sich für Sie nichts. Für die Anfragen, die sie verwenden, ist keine Aktion des Absenders erforderlich, und bestehende Signaturlinks 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 Computer öffnet, der nicht ihm gehört, und sich entfernt, stellt eine Sitzung, die nie abläuft, ein Risiko dar. Ein festes Inaktivitätsfenster plus eine harte Obergrenze begrenzen, wie lange dieses Fenster offen bleibt. Wenn Sie Vereinbarungen bearbeiten, die eine echte Vertraulichkeit erfordern, verbessert dies Ihre Sicherheitslage und hilft Ihnen, die Anforderungen an die Zugriffskontrolle zu erfüllen, auf die Frameworks wie HIPAA und SOC 2 Wert legen.

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

Löschen einer primären oder der einzigen E-Mail-Versanddomain

Das Löschen einer benutzerdefinierten E-Mail-Versanddomain war bisher blockiert, wenn es sich um Ihre primäre oder einzige Domain handelte. Diese Einschränkung gibt es nicht mehr. DELETE auf den Domain-Endpunkten für Firmen oder Workspaces funktioniert jetzt unabhängig davon, ob die Domain primär ist oder nicht.

Nachdem Sie sie gelöscht haben, fällt der ausgehende E-Mail-Versand auf den Standardabsender des Unternehmens zurück, und falls kein Unternehmensabsender festgelegt ist, auf den Standardabsender der Plattform. 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 nur deshalb behalten, weil die API das Entfernen der letzten nicht zugelassen hat.

Dies ist eine kleine Änderung, aber sie beseitigt eine echte Hürde für jeden, der Domains migriert. Eine Domain-Migration sollte kein Support-Ticket erfordern, und jetzt ist das auch nicht mehr der Fall.

Dies wurde in API v1.22.1 eingeführt.

Erste Schritte

Alle drei Änderungen sind ab sofort in der API verfügbar. Vollständige Details zu Anfragen und Antworten finden Sie im API-Changelog.

Starten Sie kostenlos mit Firma.dev, keine Kreditkarte erforderlich. Pay-as-you-go für 0,049 $ pro Umschlag (5 ¢ USD), keine monatlichen Mindestbeträge, keine Verträge.