Elektronische Signatur API auswählen: sieben Anbieter im Vergleich

Eine elektronische Signatur API (auch E-Signatur-API oder eSignature-API genannt) lässt Ihren Code ein Dokument zur Unterschrift verschicken, den Status verfolgen und die signierte Datei abholen, ohne dass jemand ein Dashboard öffnet. Wir haben sieben Anbieter danach verglichen, was sie selbst veröffentlichen. Die niedrigsten bezahlten Einstiegspunkte, die wir gefunden haben: SignWell mit 0,85 $ pro Dokument nach 25 kostenlosen im Monat, der API-Plan von PandaDoc mit 40 $ im Monat für 40 Dokumente (die Seite nennt keinen Abrechnungszyklus) und der Entwicklerplan Starter von DocuSign mit 50 $ im Monat bei jährlicher Abrechnung.

Der Preis ist der leichte Teil. Ob Ihnen eine elektronische Signatur API auch nach einem Jahr noch gefällt, entscheiden vier andere Fragen: Welche Einheit bezahlen Sie? Wie authentifiziert sich die API? Sind die Webhooks signiert? Und was ist ein Testversand rechtlich wert? Diese vier sortieren mehr Anbieter aus als jeder Listenpreis.

Wenn Sie auf Chaindoc aufbauen: Die REST-API und die Webhooks gehören zum Business-Plan, 29 € im Monat bei monatlicher Abrechnung. Jede Angabe zu einem Anbieter stammt unten von dessen eigener Seite, mit dem Datum, an dem wir sie gelesen haben.

Jede elektronische Signatur API erledigt dieselben vier Aufgaben: eine Anfrage anlegen, sie zum Unterzeichner bringen, Rückmeldung geben und die signierte Datei samt Nachweis herausgeben. Die Unterschiede liegen darin, wie jede dieser Aufgaben gebaut und abgerechnet wird. Diese Fragen lohnen sich, bevor jemand eine Demo bucht:

• Authentifizierung. OAuth, API-Schlüssel oder beides, und ob es einen reinen Lese-Schlüssel gibt, den Sie bedenkenlos im Browser ausliefern dürfen.
• Eingebettet oder per E-Mail signieren. Können Unterzeichner direkt in Ihrer Anwendung signieren, und steckt das in dem Plan, den Sie wirklich kaufen?
• Webhooks: Sind die Payloads signiert, gibt es ein Replay-Fenster, und sehen Sie, was zugestellt wurde?
• Vorlagen. Ein einziger Aufruf, der eine gespeicherte Vorlage befüllt und verschickt, erspart viel Code für die Feldplatzierung.
• Eine Sandbox, die kostenlos ist, getrennt von der Produktion läuft und ehrlich sagt, was ihre Sendungen wert sind.
• Die Preiseinheit. Umschlag (Envelope), Signaturanfrage, Dokument, Einladung oder Signatur, dazu der Abrechnungszyklus.
• Nachweis-Export: signierte PDF, Prüfpfad und Beweisdaten über die API statt über ein Dashboard.
• Branding auf der Signaturseite und in den E-Mails, und in welchem Plan es enthalten ist.
• Signaturreihenfolge und Rate Limits, die zwei Einschränkungen, die Teams am spätesten entdecken.

Die Tabelle stellt jede Frage neben das, was die Dokumentation von Chaindoc dazu sagt. So können Sie alle anderen Anbieter an derselben Liste messen.

Die Preise einer elektronischen Signatur API sind öffentlicher, als ihr Ruf vermuten lässt. Sechs der sieben Anbieter hier veröffentlichen einen Einstiegspreis. Adobe verkauft den API-Zugang mit dem Enterprise-Angebot von Acrobat Sign; ein öffentlicher API-Preis liegt uns dafür nicht vor (2026-10-14). Der Rest folgt drei Modellen:

• Entwicklerpläne mit monatlichem Kontingent: DocuSign, Dropbox Sign und PandaDoc.
• Ein Jahrespaket mit Einladungen oder eine Lizenz pro Einladung: SignNow.
• Bezahlung pro Dokument nach einem kostenlosen Monatskontingent: SignWell.

Chaindoc führt keine eigene API-Preisliste. Die API steckt im Business-Abo, die Einheit ist also dasselbe Signaturkontingent wie in der Web-App.

DocuSign API Preise nach Plan

DocuSign bepreist seine Entwicklerpläne getrennt von den eSignature-Plänen pro Nutzer. Auf der US-Preisseite für Entwickler, gelesen am 14. Oktober 2026, kostet Starter 50 $ im Monat bei jährlicher Abrechnung (600 $ im Jahr) oder 75 $ bei monatlicher Abrechnung, ab 40 Umschlägen im Monat. Intermediate kostet 300 $ im Monat bei jährlicher Abrechnung, ab 100 Umschlägen, und Advanced 480 $ im Monat bei jährlicher Abrechnung. Enhanced läuft über den Vertrieb, mit mindestens fünf Nutzern. Zum Bauen brauchen Sie keinen dieser Pläne, denn das kostenlose Entwicklerkonto reicht dafür. Zu den Plänen pro Nutzer lesen Sie DocuSigns eSignature-Pläne im Überblick.

Die meisten Anbieter einer elektronischen Signatur API nutzen eines von zwei Authentifizierungsmodellen. API-Schlüssel sind einfach: ein Geheimnis, ein Header, voller Zugriff auf Ihr eigenes Konto. OAuth 2.0 braucht mehr Einrichtung, lässt Ihre Anwendung aber mit begrenzten, widerrufbaren Rechten im Konto eines Kunden handeln. Das zählt, wenn Sie ein Produkt bauen, an das andere Unternehmen ihre eigenen E-Signatur-Konten anbinden. Das Glossar von Dropbox Sign zieht die Linie sauber: der API-Schlüssel für das eigene Konto, ein OAuth-Token für das Konto eines anderen.

Egal welches Modell, prüfen Sie drei Dinge. Gibt es einen reinen Lese-Schlüssel, den Sie in Frontend-Code legen dürfen? Lassen sich Schlüssel ohne Ausfallzeit rotieren? Und teilt sich die Sandbox ein Konto mit der Produktion, oder läuft sie getrennt davon?

Die Referenz von Chaindoc dokumentiert API-Schlüssel, kein OAuth: einen lesenden pk_-Schlüssel für den Browser und einen sk_-Schlüssel mit vollem Zugriff für den Server. Das deckt die Integration eines einzelnen Unternehmens gut ab. Für ein mandantenfähiges Produkt, bei dem jeder Kunde sein eigenes Signaturkonto mitbringt, passt ein OAuth-Ablauf besser, und DocuSign, Dropbox Sign, PandaDoc und SignNow dokumentieren jeweils einen.

Die eingebettete Signatur hält den Unterzeichner in Ihrem Produkt. Ihr Backend öffnet eine kurzlebige Sitzung, und die Signaturansicht lädt in einem iframe auf Ihrer Seite. Bei der Signatur per E-Mail geht stattdessen ein Link zur gehosteten Seite des Anbieters hinaus. Angemeldete Nutzer Ihrer Anwendung bekommen meist den ersten Weg, Gegenparteien, die nie ein Konto anlegen werden, den zweiten. Die meisten Produktivintegrationen betreiben am Ende beide, und das ist in Ordnung.

Bei Chaindoc schaltet embeddedFlow: true an der Signaturanfrage den eingebetteten Weg ein. Ihr Server ruft POST /embedded/sessions auf, übergibt die Sitzungs-ID an das Embed-SDK, und der Unterzeichner bestätigt vor dem Signieren einen Einmalcode, der an seine E-Mail-Adresse geht. Eine Sitzung dauert 10 Minuten. Lassen Sie das Flag aus, erhält der Unterzeichner stattdessen einen E-Mail-Link zu einer gehosteten Signaturseite.

Prüfen Sie, in welchem Plan die eingebettete Signatur steckt, bevor Sie eine Integration um sie herum entwerfen. In der US-Preistabelle von DocuSign für Entwickler, gelesen am 14. Oktober 2026, ist das eingebettete Senden bei jedem Entwicklerplan abgehakt, die Zeile zur eingebetteten Signatur dagegen nur bei den Enhanced-Plänen, die über den Vertrieb laufen. Fragen Sie DocuSign, welcher Plan genau den Ablauf abdeckt, den Sie ausliefern wollen. Dropbox Sign führt die eingebettete Signatur unter seinen API-Funktionen auf; in welchem Plan sie enthalten ist, liegt uns nicht vor (2026-10-14).

Bei einer Integration mit einer elektronischen Signatur API ist ein Webhook, den Ihr Server stillschweigend verwirft, schlimmer als gar keiner. Ihr System glaubt dann, den Stand des Vertrags zu kennen, und liegt falsch. Drei Prüfungen trennen ein Webhook-Design, dem Sie trauen können, von einem, das Sie um 2 Uhr nachts weckt.

Die Signatur jeder Payload prüfen

Prüfen Sie die HMAC-Signatur, bevor Sie irgendetwas im Body glauben, und berechnen Sie sie über die rohen Bytes, nie über JSON, das Sie geparst und neu serialisiert haben. Die Webhook-Dokumentation von Chaindoc signiert {timestamp}.{rawBody} mit HMAC-SHA256 und sendet den Hex-Digest mit dem Präfix v1= im Header X-Chaindoc-Signature, den Zeitstempel in X-Chaindoc-Timestamp. Wer die Prüfung auslässt, öffnet jedem, der Ihre Endpunkt-URL kennt, die Tür für ein gefälschtes Ereignis, das einen Abschluss meldet.

Replays und Duplikate abweisen

Dasselbe Ereignis kann zweimal ankommen. Speichern Sie die Delivery-ID (Chaindoc sendet eine UUID in X-Chaindoc-Delivery-Id) und ignorieren Sie Wiederholungen. Das Server-SDK von Chaindoc weist außerdem Zustellungen ab, deren Zeitstempel mehr als fünf Minuten von der Uhr Ihres Servers abweicht, und das stoppt die meisten Replays sofort.

Schnell bestätigen, später arbeiten

Chaindoc wertet eine Zustellung nur als erfolgreich, wenn Ihr Endpunkt innerhalb von 30 Sekunden mit einem 2xx antwortet. Eine fehlgeschlagene Zustellung wird mit Backoff einige Male wiederholt, dann gibt Chaindoc auf, und nach wiederholten Fehlschlägen über viele Ereignisse hinweg schaltet es die Zustellung für diesen Schlüssel ab. Antworten Sie also sofort mit 200, legen Sie das Ereignis in eine Warteschlange und erledigen Sie die langsame Arbeit dort. Webhooks gibt es nur im Business-Plan, sie werden pro API-Schlüssel im Dashboard eingerichtet, die Protokolle liegen unter Settings → API Access → Webhook logs.

Stellen Sie jedem Anbieter auf Ihrer Shortlist dieselben Fragen: Welcher Header trägt die Signatur, was genau wird signiert, wie lange läuft das Wiederholungsfenster, und wo sehen Sie, was gesendet wurde? Kann ein Anbieter nicht sagen, ob ein Webhook angekommen ist, debuggen Sie blind. Der Ereignisstrom ist zudem die Hälfte Ihrer Beweise. Lesen Sie deshalb, was ein belastbarer Prüfpfad enthält, bevor Sie entscheiden, was Sie speichern.

Eine elektronische Signatur API ist nur der Transportweg. Die Rechtswirkung kommt aus dem Recht, das für das Geschäft gilt, und aus der Signaturstufe, nicht daraus, ob die Anfrage aus einem Dashboard oder per POST-Aufruf losging.

In der EU gilt die eIDAS-Verordnung. Nach Art. 25 Abs. 1 darf einer elektronischen Signatur die Rechtswirkung und die Zulässigkeit als Beweismittel nicht allein deshalb abgesprochen werden, weil sie elektronisch ist (Verordnung (EU) Nr. 910/2014). Die Wirkung einer handschriftlichen Unterschrift hat nach Abs. 2 allein die qualifizierte elektronische Signatur (QES). Art. 26 nennt vier Anforderungen an die fortgeschrittene Stufe (AES): Die Signatur ist eindeutig dem Unterzeichner zugeordnet, ermöglicht dessen Identifizierung, wird mit Daten erstellt, die der Unterzeichner unter alleiniger Kontrolle halten kann, und ist so mit den signierten Daten verknüpft, dass jede nachträgliche Änderung erkennbar ist.

Für Deutschland kommt es auf die Form an, die das Gesetz für das Geschäft verlangt:

• Keine Form vorgeschrieben. Verlangen weder Gesetz noch Vertrag eine Form, genügt die elektronische Signatur; im Streit zählt, wie gut Sie den Ablauf belegen können.
• Textform (§ 126b BGB). Verlangt ist eine lesbare Erklärung, die den Erklärenden nennt, auf einem dauerhaften Datenträger. Eine Unterschrift fordert die Textform nicht.
• Schriftform (§ 126 BGB). Verlangt ist die eigenhändige Unterschrift. Die elektronische Form kann sie nach Absatz 3 ersetzen, wenn das Gesetz nichts anderes bestimmt, dann aber nur mit Namen und QES (§ 126a BGB); bei Verträgen signiert jede Partei ein gleichlautendes Dokument.

Vor Gericht hilft die QES zusätzlich: Nach § 371a Abs. 1 ZPO wird eine geprüfte QES beweisrechtlich wie eine private Papierurkunde behandelt, und der Anschein der Echtheit lässt sich nur durch Tatsachen erschüttern, die ernsthafte Zweifel begründen. Das deutsche Vertrauensdienstegesetz (VDG) ergänzt die Verordnung unter anderem bei Aufsicht und Pflichten der Vertrauensdiensteanbieter.

Die Anbieter stehen auf dieser Leiter auf verschiedenen Stufen, und der Plan zählt. Die Entwicklertabelle von DocuSign nennt die einfache Stufe (SES) für Starter, Intermediate und Advanced sowie SES, AES und QES für Enhanced. Die Dokumentation von Chaindoc beschreibt die eigenen Signaturen als fortgeschrittene elektronische Signaturen nach PAdES mit Blockchain-Nachweis. Chaindoc ist kein Vertrauensdiensteanbieter und stellt keine qualifizierten Zertifikate aus. Wo das Gesetz die Schriftform verlangt, muss die QES also von einem qualifizierten Anbieter kommen; ob ein Anbieter dazugehört, lässt sich in der EU-Vertrauensliste prüfen. Unser Leitfaden zur qualifizierten elektronischen Signatur erklärt, wie das abläuft. Mit Gegenparteien in den USA gilt der ESIGN Act: Danach darf einer Signatur oder einem Vertrag im zwischenstaatlichen Handel die Rechtswirkung nicht allein deshalb abgesprochen werden, weil sie elektronisch sind (15 U.S.C. § 7001(a)). Das ist eine Zusammenfassung der Gesetze, keine Rechtsberatung.

Keine elektronische Signatur API gewinnt in jeder Zeile, und ein Vergleich, der so täte, wäre für Sie nutzlos. Nach dem, was wir gelesen haben, liegt jeder Anbieter hier vorn:

• DocuSign hat das tiefste Entwickler-Werkzeug: SDKs für die gängigen Sprachen, herunterladbare Quickstart-Projekte, Postman-Collections und ein kostenloses Entwicklerkonto, das nicht abläuft. Die Enhanced-Pläne führen AES und QES in der Preistabelle auf.
• Dropbox Sign veröffentlicht offizielle SDKs in sechs Sprachen (Python, Ruby, PHP, Java, NodeJS und C#), und Testmodus-Anfragen zählen nicht gegen Ihr Kontingent.
• PandaDoc bietet eine kostenlose API-Stufe mit 60 Dokumenten im Jahr und einer vollen Sandbox, ohne Karte.
• SignNow kombiniert einen kostenlosen Dev Mode mit unbegrenzten Testeinladungen und 250 kostenlosen Einladungen zum Ausprobieren in der Produktion.
• Adobe Acrobat Sign hat eine kostenlose Developer Edition mit API-Zugang, dazu ein eigenes OEM- und Embedded-Partnerprogramm für Softwarehersteller.
• SignWell hat den niedrigsten Einstiegspreis pro Einheit, den wir gefunden haben: ab 0,85 $ pro Dokument nach 25 kostenlosen im Monat.
• Chaindoc legt API-Schlüssel und Webhooks in einen einzigen Pauschalplan in Euro, ergänzt jede veröffentlichte Dokumentversion um einen Blockchain-Verifizierungsdatensatz und führt Verträge samt Rechnungen über dieselbe API. Auch die Grenzen sind real: zwei TypeScript-SDKs (jeder HTTP-Client funktioniert), per API gleichzeitig versendete Einladungen, keine eigenen qualifizierten Zertifikate und eine Rate-Begrenzung pro Schlüssel.

Ersetzen Sie gerade DocuSign, geht unsere Seite dazu, wie Chaindoc im Vergleich zu DocuSign abschneidet, Plan für Plan vor.

API-Schlüssel und Webhooks der Chaindoc API gibt es mit dem Business-Plan: 29 € im Monat bei monatlicher Abrechnung oder 278 € bei jährlicher, mit 100 Signaturen im Monat und 9 € im Monat für je 10 weitere (siehe die Pläne von Chaindoc). Im Team-Plan ist der API-Zugang auf Anfrage möglich; Free und Personal enthalten ihn nicht.

Gut passt die API zu einem Produkt, das Signatur, Nachweis und Zahlung in einem Ablauf braucht. Dieselbe API legt Dokumente an, versendet Signaturanfragen, befüllt Vorlagen und führt Verträge mit Rechnungen und Zahlungseinrichtung. Veröffentlichen Sie ein Dokument, wird der Hash der Version, den der Server beim Upload berechnet hat, on chain geschrieben, und der Nachweis jedes Unterzeichners wird festgehalten, sobald die Anfrage abgeschlossen ist. GET /documents/versions/:versionId/verification liefert Transaktions-Hash und Chain-ID, die Sie zu Ihren eigenen Unterlagen legen. Identitätsprüfungen sind optional, pro Anfrage: Setzen Sie isKycRequired: true, wenn ein Geschäft eine braucht; Business enthält 10 im Monat.

Schlecht passt ein Ablauf, der über die API von einer Signaturreihenfolge abhängt. Eine über die API gestellte Anfrage lädt alle gleichzeitig ein; eine feste Reihenfolge gibt es über Freigabewege in der Web-App im Business-Plan. Und wenn agentengesteuerte Abläufe auf Ihrer Roadmap stehen: Das öffentliche Paket @chaindoc_io/mcp-server setzt auf derselben API auf; Chaindocs MCP-Server für KI-Agenten behandelt es.

Geben Sie jedem Finalisten dieselben fünf Tage.

1. 1.
   Authentifizieren und in der Sandbox eine Anfrage aus einer Vorlage senden.
2. 2.
   Den eingebetteten und den E-Mail-Weg bauen.
3. 3.
   Webhook-Signaturen prüfen, eine Zustellung wiederholen und den eigenen Endpunkt eine Stunde abschalten, um zu sehen, was die Wiederholungen tun.
4. 4.
   Die signierte Datei und den Prüfnachweis über die API exportieren. Der Schritt fällt am leichtesten unter den Tisch und zeigt am deutlichsten, was Sie einem Gericht vorlegen könnten.
5. 5.
   Das echte Monatsvolumen in der Einheit jedes Anbieters bepreisen, mit dem Abrechnungszyklus, den Sie tatsächlich wählen würden.

Die elektronische Signatur API, die diese Woche ohne Support-Ticket übersteht, ist meist die, die Sie kaufen sollten.