Neu in Firma.dev: White-Labeling für Ihre Signaturseite – bis ins kleinste Detail der Buttons

Die Signaturseite von Firma.dev trägt bereits Ihre Marke: Ihr Logo, Ihre Farben, Ihre Unterzeichnerbedingungen, Ihre E-Mails und Ihre Abschlussseite. Seit API v1.40.0, veröffentlicht am 17. Oktober 2026, folgt sie auch Ihren Regeln dazu, was ein Unterzeichner darauf tun kann. Zwei neue Einstellungen blenden die Schaltflächen „Decline to Sign“ und „Save & Finish Later“ auf gehosteten und eingebetteten Signaturseiten aus, sodass eine SaaS-Plattform, die eingebettetes Signieren in ihrem eigenen Produkt betreibt, nun darüber entscheidet, welche Aktionen ihren Unterzeichnern zur Verfügung stehen.

Neu: Bestimmen Sie, welche Schaltflächen Ihre Unterzeichner sehen

Das Release fügt zwei Schalter hinzu. allow_decline steuert die Schaltfläche „Decline to Sign“ und show_save_for_later steuert „Save & Finish Later“. Beide gelten sowohl für die gehostete Signaturseite als auch für das eingebettete Signatur-iFrame, und beide sind standardmäßig sichtbar, sodass Ihre Signaturseiten genau so bleiben, wie sie sind, bis Sie einen Wert festlegen.

Das Ausblenden von „Decline to Sign“ wird erzwungen. Wenn allow_decline auf false gesetzt ist, lehnt Firma.dev jede Ablehnung für diese Signaturanfrage ab – sowohl für Unterzeichner als auch für Genehmigende –, und die Anfrage kann nur durch Stornieren beendet werden... wodurch die Entscheidung über die Ablehnung in die Hände Ihres Produkts gelegt wird. Das Ausblenden von „Save & Finish Later“ entfernt lediglich die Schaltfläche.

Ihre Signaturseite, durchgängig als White-Label

Die Sichtbarkeit von Schaltflächen ist die neueste Ebene eines White-Label-Stacks, den SaaS-Plattformen bereits nutzen, damit eingebettetes Signieren wie ein nativer Teil ihrer eigenen App aussieht und funktioniert. Die aktuellen Steuerelemente, gruppiert danach, wo der Unterzeichner ihnen begegnet:

Auf der Signaturseite

• Schaltflächen der Signaturseite (neu): Ein- oder Ausblenden von „Decline to Sign“ und „Save & Finish Later“.

• Schaltflächenbeschriftungen: Benennen Sie neun Schaltflächen der Signaturansicht pro Sprache mit signing_button_label_overrides um, einschließlich „Decline to Sign“ und „Save & Finish Later“. Mehr dazu unter benutzerdefinierte Beschriftungen für Signaturschaltflächen.

• Farbdesign: 11 color_*-Hex-Einstellungen auf Unternehmens- und Arbeitsbereichsebene. Fünf davon passen auch das Design der eingebetteten Editoren an.

• Anzeigeeinstellungen: Signaturrahmen, partielles Wasserzeichen, QR-Code, E-Mail-OTP-Verifizierung, Akzeptanz der Bedingungen, geführte Navigation und Download vor dem Signieren.

• Unterzeichnerbedingungen: Ihre eigene Einwilligungserklärung pro Sprache mit einem optionalen Link zu den Bedingungen.

• Feldhintergrundfarben und eine Signatur-Benutzeroberfläche in 15 Sprachen, ausgewählt über den Parameter lang.

Einbettung

• Eingebettetes Signieren in einem iFrame, das die postMessage-Ereignisse signing.started, signing.completed, signing.declined und signing.error ausgibt. Der Quickstart für die API zur eingebetteten E-Signatur führt Sie hindurch.

• Einbettbare Editoren für Vorlagen und Signaturanfragen mit Design- und Schließen-Steuerelementen.

E-Mails

• Eine benutzerdefinierte Absendedomäne, verifiziert mit SPF, DKIM und DMARC, sowie Ihr eigener lokaler Teil der Absenderadresse.

• Ihr Logo (PNG oder JPEG, bis zu 2 MB) auf Signatur-E-Mails und -Zertifikaten.

• Benutzerdefinierte E-Mail-Vorlagen auf Unternehmens- oder Arbeitsbereichsebene sowie Schalter pro Anfrage, die Signatur-, Abschluss-, Ablauf- und Stornierungs-E-Mails von Firma.dev deaktivieren. Siehe White-Label-E-Mails und Signatur-Links für E-Signaturen.

Nach dem Signieren

• Eine Abschlussseite mit Ihrem eigenen Titel, Ihrer eigenen Nachricht und HTTPS-Weiterleitung, beschrieben unter Anpassung der Abschlussseite.

• Organisationssiegel mit Ihrem Firmenstempel auf fertiggestellten PDFs.

Pro Kunde

• Mit Kundenarbeitsbereichen kann sich jede Einstellung, die die Arbeitsbereichsebene unterstützt, von einem Kunden zum nächsten unterscheiden.

Beschriftungen und Sichtbarkeit lassen sich kombinieren, sodass ein Arbeitsbereich „Decline to Sign“ in „Änderungen anfordern“ umbenennen kann, während ein anderer Arbeitsbereich die Schaltfläche komplett ausblendet. Die vollständige Anleitung zur White-Label-E-Signatur-API behandelt jedes Steuerelement im Detail, und die Funktionsseite für White-Label-E-Signaturen bietet die Übersicht. All dies ist zum gleichen Preis wie alles andere in den Preisen von Firma.dev verfügbar: 0,049 € pro Umschlag (~5¢ USD), Pay-as-you-go, ohne monatliche Mindestbeträge und ohne Gebühren pro Benutzerplatz.

Vier Ebenen, die spezifischste gewinnt

Jede Schaltfläche kann auf vier Ebenen festgelegt werden: Unternehmen, Arbeitsbereich, Vorlage und Signaturanfrage. Firma.dev liest zuerst den eigenen Wert der Signaturanfrage. Wenn dieser null ist, gilt der Wert des Arbeitsbereichs, und wenn der Arbeitsbereich ebenfalls null ist, gilt der Unternehmenswert. Der Unternehmensstandard ist true, weshalb sich nichts ändert, bis Sie dies anpassen. Zwei Timing-Regeln sind wichtig, sobald dies in Produktion ist.

Vorlagen kopieren bei der Erstellung

Eine aus einer Vorlage erstellte Signaturanfrage kopiert die Werte der Vorlage in dem Moment, in dem sie erstellt wird. Ein Wert, den Sie in den settings des Erstellungsaufrufs übergeben, überschreibt die Vorlage, und null greift auf den Arbeitsbereich zurück. Eine spätere Bearbeitung der Vorlage hat keine Auswirkungen auf bereits daraus erstellte Anfragen.

Änderungen an Arbeitsbereich und Unternehmen erreichen bereits gesendete Anfragen

Jede Signaturanfrage, deren eigener Wert null ist, übernimmt eine Änderung des Arbeitsbereichs oder des Unternehmens, einschließlich bereits zum Signieren versandter Anfragen. Wenn Sie allow_decline in einem aktiven Arbeitsbereich auf false umstellen, verliert jede offene Anfrage ohne eigenen Wert ebenfalls die Ablehnen-Schaltfläche... prüfen Sie also vorher, was gerade im Umlauf ist.

Wo es im Dashboard zu finden ist

• Unternehmen: Einstellungen > Unternehmenseinstellungen, unter Schaltflächen der Signaturseite. Zwei Schalter legen den Standard für jeden Arbeitsbereich fest.

• Arbeitsbereich: der Tab „Einstellungen“ des Arbeitsbereichs unter Schaltflächen der Signaturseite. Wählen Sie „Anzeigen“, „Ausblenden“ oder „Unternehmensstandard verwenden“, und die Änderung wird sofort gespeichert.

• Vorlage und Signaturanfrage: der Tab „Dokumenteinstellungen“ in der Editor-Seitenleiste mit „Anzeigen“, „Ausblenden“ oder „Arbeitsbereichsstandard verwenden“. Eine Signaturanfrage kann geändert werden, bis sie gesendet wird.

Führen Sie Ihren eigenen Ablehnungs-Flow in Ihrem Produkt aus

Wenn ein Unterzeichner ablehnt, benötigen viele Produkte den Grund dafür. Ein Vertriebstool möchte ihn im Deal-Datensatz haben, eine Kredit-App möchte, dass ein Kreditsachbearbeiter zurückruft, und ein Marktplatz möchte ein überarbeitetes Angebot senden. Mit allow_decline: false verweigert Firma.dev jede Ablehnung bei der Anfrage, sodass die Ablehnen-Schaltfläche in Ihrer eigenen Benutzeroberfläche zur einzigen Möglichkeit wird, wie ein Unterzeichner ablehnen kann.

Ein typischer Ablauf sieht wie folgt aus:

1. Setzen Sie allow_decline: false für die Signaturanfrage, deren Vorlage oder den Arbeitsbereich und betten Sie die Signaturseite in ein iFrame ein, das auf https://app.firma.dev/signing/{signing_request_user_id} verweist.

2. Platzieren Sie Ihre eigene Ablehnen-Schaltfläche neben dem iFrame. Wenn der Unterzeichner darauf klickt, öffnen Sie Ihren eigenen Dialog und erfassen Sie einen Grund.

3. Leiten Sie diesen Grund dorthin weiter, wo er hingehört: in eine CRM-Notiz, eine Benachrichtigung an den Account Manager, ein Support-Ticket.

4. Stornieren Sie die Signaturanfrage von Ihrem Backend aus mit dem beigefügten Grund.

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/SIGNING_REQUEST_ID/cancel \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Signer declined in app: pricing", "notify_signers": true}'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/SIGNING_REQUEST_ID/cancel \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Signer declined in app: pricing", "notify_signers": true}'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/SIGNING_REQUEST_ID/cancel \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Signer declined in app: pricing", "notify_signers": true}'

reason ist optional und auf 500 Zeichen begrenzt. notify_signers ist standardmäßig auf true gesetzt. Setzen Sie es also auf false, wenn Ihr Produkt eine eigene Nachricht an den Unterzeichner sendet. Das Stornieren funktioniert bei einer Anfrage, die gesendet wurde und noch nicht abgeschlossen oder storniert ist, andernfalls wird 409 zurückgegeben. Dieselbe Regel gilt für Genehmigende, da ein ausgeblendetes Ablehnen für jeden Teilnehmer der Anfrage gilt.

Firma.dev ist konform mit dem ESIGN Act, UETA, eIDAS (SES und AES) sowie UK eIDAS, und Signaturen sind in über 55 Ländern rechtsverbindlich, unabhängig davon, welche Schaltflächen Sie anzeigen.

Formulare mit einer einzigen Signatur

Ein einseitiges Formular mit einer einzigen Signatur erfordert kein späteres Fortsetzen... blenden Sie „Save & Finish Later“ in dieser Vorlage aus, und der Unterzeichner muss über eine Schaltfläche weniger nachdenken.

Ein Workflow, unterschiedliche Regeln

Behalten Sie „Decline“ als Unternehmensstandard bei und deaktivieren Sie es für eine einzelne Vorlage... beispielsweise für eine Bestätigung interner Richtlinien, bei der eine Ablehnung nicht Teil des Prozesses ist. Jede andere Vorlage behält die Schaltfläche.

Richten Sie es mit der API ein

Alle vier Ebenen verwenden dieselben zwei Schlüssel. Der Unternehmensstandard akzeptiert nur true oder false:

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/company/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": true, "show_save_for_later": true}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/company/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": true, "show_save_for_later": true}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/company/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": true, "show_save_for_later": true}'

Ein Arbeitsbereich-Override akzeptiert null, um auf den Unternehmenswert zurückzugreifen:

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/workspace/WORKSPACE_ID/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": false, "show_save_for_later": null}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/workspace/WORKSPACE_ID/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": false, "show_save_for_later": null}'

curl -X PUT https://api.firma.dev/functions/v1/signing-request-api/workspace/WORKSPACE_ID/settings \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allow_decline": false, "show_save_for_later": null}'

Pro Anfrage gehören die Schlüssel in settings bei POST /signing-requests oder POST /signing-requests/create-and-send. Dieses Beispiel verwendet die Empfänger der Vorlage, da keine übergeben werden:

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order form - Acme",
    "template_id": "TEMPLATE_ID",
    "settings": {"allow_decline": false, "show_save_for_later": false}
  }'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order form - Acme",
    "template_id": "TEMPLATE_ID",
    "settings": {"allow_decline": false, "show_save_for_later": false}
  }'

curl -X POST https://api.firma.dev/functions/v1/signing-request-api/signing-requests/create-and-send \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Order form - Acme",
    "template_id": "TEMPLATE_ID",
    "settings": {"allow_decline": false, "show_save_for_later": false}
  }'

Bei PUT /signing-requests/{id} befindet sich dasselbe Objekt unter signing_request_properties.settings und bei PUT /templates/{id} unter template_properties.settings. POST /templates und die PATCH-Routen erwarten ein übergeordnetes settings. Jeder andere Wert als true, false oder null gibt 400 VALIDATION_ERROR mit Nennung des Schlüssels zurück, und es wird nichts gespeichert. Die vollständige Routentabelle befindet sich im API-Changelog für v1.40.0.

Ebenfalls in v1.40.0: Ein eindeutiger 413 für zu große Anfragen

Anfrage-Bodys über 6 MiB geben jetzt 413 REQUEST_TOO_LARGE mit dem standardmäßigen error- und code-Body zurück. Zuvor antwortete das Gateway mit einem 502, was nur sehr wenig darüber aussagte, was schiefgelaufen war. Fordern Sie für größere Dateien eine Upload-URL mit POST /documents an, laden Sie die Datei dorthin hoch und übergeben Sie document_id oder document_ids in Ihrem Erstellungsaufruf.

Kurz gesagt: Mit v1.40.0 können Sie „Decline to Sign“ und „Save & Finish Later“ auf Unternehmens-, Arbeitsbereichs-, Vorlagen- oder Anfrageebene ausblenden. Ein ausgeblendetes Ablehnen wird erzwungen, und der Stornierungs-Endpunkt bietet Ihrem eigenen Ablehnungs-Flow eine saubere Möglichkeit, die Anfrage zu schließen. Und all dies setzt auf dem Logo, den Farben, den Beschriftungen, den Unterzeichnerbedingungen, den E-Mails und der Abschlussseite auf, die Sie bereits kontrollieren.

Starten Sie kostenlos mit Firma.dev – keine Kreditkarte erforderlich.