Wie man eine Document Signatur-API in sein SaaS-Produkt als White-Label integriert

Suchen Sie nach der vollständigen Aufschlüsselung? Dieser Beitrag behandelt die wichtigsten Konzepte und Entscheidungen. Eine umfassende Schritt-für-Schritt-Anleitung zu jeder White-Label-Funktion, einschließlich Logos, Farbthemen, benutzerdefinierten E-Mail-Vorlagen, Absenderadressen und Codebeispielen, finden Sie unter The Complete Guide to White-Label E-Signatures for SaaS.

Wenn Sie eine API für Dokumentensignaturen in Ihr Produkt integrieren, sollten Ihre Kunden nicht das Gefühl haben, die Software eines Drittanbieters zu verwenden. Das Signaturerlebnis sollte wie Ihr Produkt aussehen und sich auch so anfühlen, nicht wie ein Tool von Drittanbietern.

White-Labeling macht das möglich. Die meisten Entwickler denken jedoch, dass White-Labeling nur bedeutet, ein Logo aufzuklatschen. In der Praxis ist es nuancierter. Eine vollständig gebrandete Integration einer digitalen Signatur-API umfasst visuelles Branding, E-Mail-Anpassung, Benachrichtigungssteuerung und eingebettete Schnittstellen – und Sie benötigen nicht immer alle davon. Den vollständigen Umfang dessen, was Sie branden können, finden Sie in der Funktionsübersicht der White-Label-E-Signatur-API.

Dieser Leitfaden schlüsselt auf, was jede Ebene bewirkt, wann sie zu verwenden ist und wie Sie eine White-Label-PDF-Signatur-API implementieren, die zu Ihrem Produkt passt.

Was White-Labeling für E-Signaturen tatsächlich bedeutet

Wenn ein Kunde ein Dokument über Ihre App signiert, tragen mehrere Berührungspunkte das Branding:

• Die Signaturoberfläche selbst (Logo, Farben, Layout)

• Die E-Mail, die den Kunden darüber benachrichtigt, dass ein Dokument zur Signatur bereitsteht

• Die Absenderadresse und die E-Mail-Vorlage

• Abschluss- und Erinnerungsbenachrichtigungen

• Alle rechtlichen Bedingungen oder Annahmeschritte

Standardmäßig versehen die meisten Signatur-APIs all diese Punkte mit ihrem eigenen Namen. Mit White-Labeling können Sie dieses Branding durch Ihr eigenes ersetzen oder es vollständig entfernen.

Das Ziel ist einfach: Ihre Kunden interagieren während des gesamten Signatur-Workflows mit Ihrer Marke. Sie sehen den dahinterstehenden API-Anbieter nie.

Die vier Ebenen des White-Labelings

Ebene 1: Visuelles Branding

Der unmittelbarste Effekt. Laden Sie Ihr Logo hoch, legen Sie Ihre Farbpalette fest und blenden Sie das Branding des API-Anbieters vollständig aus dem Signaturerlebnis aus.

Mit Firma.dev steuern Sie sechs Farbeinstellungen (primärer Akzent, Vordergrundtext, Hintergrund, Kartenfarbe und Rahmenfarbe) und können Logos sowohl auf Unternehmens- als auch auf Workspace-Ebene hochladen. Für mandantenfähige SaaS-Produkte bedeutet dies, dass jeder Ihrer Kunden seine eigene, unverwechselbare visuelle Identität im Signaturfluss haben kann.

Aktivieren Sie show_custom_branding_only, und die Signaturoberfläche sieht aus, als wäre sie von Ihrem Team entwickelt worden. Keine Logos von Drittanbietern, keine ungewohnten Farbschemata.

Diese Ebene ist in wenigen Minuten implementiert und hat die größte sichtbare Wirkung. Beginnen Sie hier, selbst wenn Sie die anderen Ebenen erst später hinzufügen möchten.

Ebene 2: Gebrandete E-Mail-Domains und Vorlagen

Anstatt Signaturanfragen von noreply@signatureprovider.com zu senden, kommen E-Mails von Ihrer Domain, z. B. documents@yourcompany.com. Sie steuern auch den lokalen Teil der Absenderadresse (den Teil vor dem @), sodass Sie noreply, signing, contracts oder was auch immer zu Ihrem Produkt passt, verwenden können.

Über den Absender hinaus können Sie die E-Mail-Vorlagen selbst anpassen. Firma.dev unterstützt benutzerdefinierte HTML-Vorlagen für 11 E-Mail-Typen (Signatureinladungen, Abschlüsse, Erinnerungen, Ablaufwarnungen und mehr) mit dynamischen Platzhaltern für Unterzeichnernamen, Signaturlinks, Unternehmenslogos und Teamdetails. Legen Sie Vorlagen auf Unternehmensebene fest, um Konsistenz zu gewährleisten, und überschreiben Sie diese bei Bedarf pro Workspace.

Für mandantenfähige SaaS-Produkte bedeuten E-Mail-Domains auf Workspace-Ebene, dass jeder Ihrer Kunden von seiner eigenen Domain aus senden kann. Eine Immobilienverwaltungsplattform könnte beispielsweise Signatur-E-Mails von leases@buildingname.com für jede Immobilie senden lassen.

Wenn Sie nach einer schnellen Implementierung suchen, finden Sie in der Schritt-für-Schritt-Anleitung unter How to White-Label Your E-Signature Emails and Signing Links weitere Details.

Ebene 3: Benachrichtigungssteuerung

Gebrandete E-Mails und benutzerdefinierte Vorlagen sind gut. Die volle Kontrolle über die Benachrichtigungen ist besser.

Die meisten APIs für digitale Signaturen versenden automatisierte E-Mails für Signaturanfragen, Abschlussbestätigungen, Ablaufwarnungen und Stornierungshinweise. Eine White-Label-Konfiguration ermöglicht es Ihnen, jede oder alle dieser Benachrichtigungen pro Signaturanfrage zu deaktivieren.

Warum sollten Sie diese deaktivieren wollen? Weil Sie möglicherweise Folgendes tun möchten:

• Signaturlinks über Ihre eigene E-Mail-Infrastruktur senden

• Benachrichtigungen in bestehende Kommunikationsflüsse mit Kunden integrieren

• Das Timing von Erinnerungen und Nachfassaktionen steuern

• E-Mails basierend auf Ihrer eigenen Geschäftslogik auslösen

Wenn Sie die E-Mails der API deaktivieren, rufen Sie die Signatur-URLs direkt von der API ab und verteilen sie nach Ihren Wünschen. Dies ist besonders nützlich, wenn Sie bereits über eine Infrastruktur für transaktionale E-Mails verfügen (SendGrid, Postmark, Customer.io) und möchten, dass Signaturbenachrichtigungen über dasselbe System laufen.

Ebene 4: Eingebettete Signaturerlebnisse

Dies ist die vollständige White-Label-Lösung. Anstatt Benutzer auf eine Signaturseite eines Drittanbieters weiterzuleiten, betten Sie die Signaturoberfläche direkt in Ihre Anwendung ein.

Bei eingebetteten Signaturen findet der gesamte Workflow innerhalb Ihres Produkts statt. Benutzer verlassen Ihre Domain nie. Sie sehen Ihre Kopfzeile, Ihre Navigation, Ihr Design. Die Signatur-Benutzeroberfläche erscheint als nahtloser Teil Ihrer App, gerendert mit Ihrem Logo und Ihren Farben.

Die meisten APIs für PDF-Signaturen bieten einbettbare Komponenten für:

• Signieren: Der eigentliche Ablauf der Dokumentenunterzeichnung

• Vorlagenbearbeitung: Ermöglicht es Benutzern, Signaturfelder und Platzhalter zu definieren

• Konfiguration von Signaturanfragen: Einrichten von Empfängern, Reihenfolge und Optionen

Eingebettete Erlebnisse verwenden in der Regel die JWT-Authentifizierung (JSON Web Token). Ihr Backend generiert ein kurzlebiges Token, und das Frontend lädt die eingebettete Komponente mit diesem Token. Es werden keine API-Schlüssel für den Client offengelegt.

Das Branding des eingebetteten Workflows geht nun noch einen Schritt weiter als die Benutzeroberfläche selbst. Der Text des Signatur-Buttons für den Unterzeichner ist pro Sprache anpassbar, sodass die Buttons in Ihrer eingebetteten Signaturansicht dem Wortlaut Ihres Produkts entsprechen können, anstatt generische Standards zu übernehmen. Siehe customizable signing button labels für Informationen zur Einrichtung.

Für SaaS-Produkte, bei denen das Signieren von Dokumenten ein Kernfeature ist, lohnt sich der Aufwand für die Implementierung einer eingebetteten Signatur meist. Ihr Produkt fühlt sich konsistenter an, und Sie behalten die volle Kontrolle über das Benutzererlebnis.

Den richtigen Ansatz wählen

Nicht jede Integration erfordert ein vollständiges White-Labeling. So können Sie sich entscheiden:

Logo, Farben und gebrandete E-Mails eignen sich gut, wenn das Signieren eine sekundäre Funktion ist. Ihre Kunden erhalten eine professionelle, gebrandete Erfahrung ohne nennenswerten Entwicklungsaufwand. Die Implementierung dauert ein paar Stunden, hauptsächlich DNS-Konfiguration und ein paar API-Aufrufe für das visuelle Branding.

Das Obige + benutzerdefinierte E-Mail-Vorlagen eignet sich für Produkte, bei denen Sie eine gebrandete Kommunikation wünschen, ohne Ihre E-Mail-Infrastruktur zu ersetzen. Sie passen den Inhalt und das HTML der Signatur-E-Mails an, während Firma.dev die Zustellung übernimmt. Dies erfordert ein bis zwei Stunden zusätzliche Arbeit an den Vorlagen.

Das Obige + Benachrichtigungssteuerung ist der richtige Schritt, wenn Sie die Kommunikationsebene vollständig selbst kontrollieren möchten. Möglicherweise haben Sie spezielle Compliance-Anforderungen bezüglich E-Mails oder möchten, dass Signaturbenachrichtigungen über Ihr bestehendes Transaktionssystem laufen. Dies bedeutet ein bis zwei Tage Integrationsarbeit.

Vollständig eingebettetes Erlebnis ist die richtige Wahl, wenn das Signieren für Ihr Produkt zentral ist. HR-Plattformen, Vertragsverwaltungstools, Immobiliensoftware, Onboarding-Systeme im Gesundheitswesen. Wenn Ihre Kunden viel Zeit in Signatur-Workflows verbringen, zahlt sich die Einbettung dieses Erlebnisses aus. Rechnen Sie mit einigen Tagen bis zu einer Woche Integrationsarbeit, je nachdem, wie viele Komponenten Sie einbetten.

Überlegungen zur Implementierung

Einige Dinge, die Sie vor dem Start bedenken sollten:

1. Workspaces und Mandantenfähigkeit. Wenn Sie ein mandantenfähiges SaaS-Produkt entwickeln, suchen Sie nach einer API für Dokumentensignaturen, die Kunden-Workspaces unterstützt. Jeder Ihrer Kunden erhält eine isolierte Umgebung mit eigenen Vorlagen, Signaturverläufen, Branding und (optional) E-Mail-Domains. Dadurch bleiben die Daten sauber getrennt, ohne dass Sie die Mandantentrennung selbst entwickeln müssen.

2. Die Hierarchie der Einstellungen. Die Branding-Einstellungen in Firma.dev sind kaskadierend aufgebaut: Workspace überschreibt Firma, Firma überschreibt Standardwerte. Das bedeutet, dass Sie das firmenweite Branding einmal festlegen und nur bei Bedarf Abweichungen auf Workspace-Ebene konfigurieren. Wenn Sie einen Workspace-Wert auf null setzen, übernimmt er die Werte der Unternehmensebene.

3. Sicherheit. Generieren Sie JWT-Token auf Ihrem Backend, niemals im clientseitigen Code. Halten Sie die Gültigkeitsdauer der Token kurz (typisch sind 1–4 Stunden). Validieren Sie die Herkunft von iframe-Nachrichten, wenn Sie Ereignisse von eingebetteten Komponenten verarbeiten.

4. Compliance. White-Labeling ändert nichts an der Rechtsgültigkeit von Signaturen. Eine gut konzipierte API für digitale Signaturen gewährleistet die Einhaltung von ESIGN, UETA und eIDAS unabhängig vom Branding. Stellen Sie sicher, dass Ihr Anbieter die regulatorischen Rahmenbedingungen unterstützt, die für Ihre Kunden relevant sind.

5. Kosten. Enterprise-Signaturplattformen verlangen oft hohe Gebühren für White-Label-Funktionen. Einige Anbieter integrieren White-Labeling in alle Tarife. Firma.dev bietet alle White-Labeling-Funktionen mit nutzungsbasierter Abrechnung für 0,049 € pro Umschlag (~5¢ USD), ohne Verträge oder Mindestumsätze.

Erste Schritte

Wenn Sie APIs für Dokumentensignaturen für eine White-Label-Integration evaluieren, sollten Sie zunächst festlegen, welche Berührungspunkte für Ihre Kunden am wichtigsten sind. Ist ihnen das E-Mail-Branding wichtig? Müssen sie den Signaturfluss einbetten? Die Antworten werden den Umfang Ihrer Implementierung bestimmen. Für das breitere strategische Gesamtbild bei Single-Brand- und Mandanten-Setups siehe die Vollständige Anleitung zu White-Label-E-Signaturen für SaaS.

Für eine detaillierte technische Einführung bietet das Firma.dev White Labeling Guide Codebeispiele für benutzerdefinierte E-Mail-Domains, Benachrichtigungseinstellungen und eingebettete Komponenten.

Bereit zum Entwickeln? Holen Sie sich Ihren API-Schlüssel und starten Sie die Integration in wenigen Stunden statt Wochen.