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 Anleitung zu allen White-Label-Funktionen, 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 nutzen. 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 das nuancierter. Eine vollständig gebrandete Integration einer API für digitale Signaturen 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 zur white-label e-signature API.

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

Was White-Labeling bei E-Signaturen tatsächlich bedeutet

Wenn ein Kunde ein Dokument über Ihre App unterzeichnet, weisen mehrere Berührungspunkte ein Branding auf:

• Die Signaturschnittstelle selbst (Logo, Farben, Layout)

• Die E-Mail, die sie darüber informiert, dass ein Dokument zur Unterzeichnung bereitsteht

• Die Absenderadresse und 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 zugrunde liegenden 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 (Hauptakzent, 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 visuelle Identität im Signaturfluss haben kann.

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

Die Implementierung dieser Ebene dauert nur wenige Minuten und erzielt 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.

Neben dem Absender können Sie auch 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 für Konsistenz fest 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 unter How to White-Label Your E-Signature Emails and Signing Links eine schrittweise Anleitung.

Ebene 3: Benachrichtigungssteuerung

Gebrandete E-Mails und benutzerdefinierte Vorlagen sind gut. Die vollständige Kontrolle über Benachrichtigungen ist besser.

Die meisten APIs für digitale Signaturen senden automatisierte E-Mails für Signaturanfragen, Abschlussbestätigungen, Ablaufwarnungen und Stornierungshinweise. Eine White-Label-Konfiguration ermöglicht es Ihnen, einzelne oder alle diese 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 Kundenkommunikationsflüsse 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, wie Sie möchten. Dies ist besonders nützlich, wenn Sie bereits über eine gebührenpflichtige E-Mail-Infrastruktur (SendGrid, Postmark, Customer.io) verfügen und möchten, dass die 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 Signaturschnittstelle direkt in Ihre Anwendung ein.

Mit eingebetteter Signatur findet der gesamte Workflow innerhalb Ihres Produkts statt. Benutzer verlassen Ihre Domain nie. Sie sehen Ihre Kopfzeile, Ihre Navigation, Ihr Design. Die Signaturbenutzeroberfläche erscheint als nahtloser Teil Ihrer App, dargestellt mit Ihrem Logo und Ihren Farben.

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

• Signieren: Der eigentliche Workflow zur 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 an den Client weitergegeben.

Das Branding des eingebetteten Workflows geht nun noch einen Schritt weiter als die Schnittstelle selbst. Der für den Unterzeichner sichtbare Text des Buttons ist pro Sprache anpassbar, sodass die Buttons in Ihrer eingebetteten Signaturansicht an die Formulierung Ihres Produkts angepasst werden können, anstatt allgemeine Standardwerte zu übernehmen. Unter customizable signing button labels erfahren Sie, wie Sie diese einrichten.

Für SaaS-Produkte, bei denen die Dokumentenunterzeichnung ein Kernfeature ist, lohnt sich der Implementierungsaufwand für das eingebettete Signieren in der Regel. 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 entscheiden Sie sich:

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

Obiges + benutzerdefinierte E-Mail-Vorlagen passt zu Produkten, bei denen Sie gebrandete Kommunikationsmittel 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.

Obiges + 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 von zentraler Bedeutung 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 customer workspaces unterstützt. Jeder Ihrer Kunden erhält eine isolierte Umgebung mit eigenen Vorlagen, einem eigenen Signaturverlauf, eigenem Branding und (optional) einer eigenen E-Mail-Domain. Dies hält die Daten sauber getrennt, ohne dass Sie die Mandantenisolierung selbst entwickeln müssen.

2. Die Einstellungshierarchie. Branding-Einstellungen in Firma.dev vererben sich kaskadierend: Der Workspace überschreibt das Unternehmen, das Unternehmen überschreibt die Standardeinstellungen. Das bedeutet, dass Sie das unternehmensweite Branding nur einmal festlegen und Workspace-spezifische Überschreibungen nur bei Bedarf konfigurieren. Wenn Sie einen Workspace-Wert auf null setzen, erbt dieser die Einstellungen der Unternehmensebene.

3. Sicherheit. Generieren Sie JWT-Token auf Ihrem Backend, niemals im clientseitigen Code. Halten Sie die Gültigkeitsdauer der Token kurz (üblich sind 1 bis 4 Stunden). Validieren Sie die Herkunft von Iframe-Nachrichten (Message Origins), 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 für Ihre Kunden relevanten regulatorischen Rahmenbedingungen unterstützt.

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,029 € pro Umschlag (~3¢ USD) an, 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? Benötigen sie einen eingebetteten Signaturfluss? Die Antworten werden den Umfang Ihrer Implementierung bestimmen. Für das breitere strategische Bild über Einzelmarken- und mandantenfähige Setups hinweg siehe den complete guide to white-label e-signatures for SaaS.

Für eine detaillierte technische Anleitung deckt der Firma.dev White Labeling Guide benutzerdefinierte E-Mail-Domains, Benachrichtigungseinstellungen und eingebettete Komponenten mit Codebeispielen ab.

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