Was wir im Januar 2026 versendet haben

Januar war ein arbeitsreicher Monat. Wir haben eine Reihe von Updates für Firma.dev ausgeliefert, über die wir uns sehr freuen, und die meisten davon stammen direkt aus dem Feedback, das wir von Entwicklern erhalten haben, die auf der API aufbauen.

Das Thema dieses Monats war es, die API schneller, flexibler und einfacher zu integrieren. Einige dieser Änderungen sind kleine Verbesserungen der Benutzerfreundlichkeit. Andere erschließen völlig neue Workflows. Wir sind jetzt bei Version 1.2.0, und alles hier ist heute live.

Hier ist die Zusammenfassung.

40% Schnellere Signaturanfragen

Wir haben ein paar Wochen damit verbracht, die Leistung zu analysieren, und es geschafft, unsere durchschnittliche Latenzzeit für Signaturanfragen von 820 ms auf etwa 500 ms zu reduzieren. Das ist eine Verbesserung von etwa 40 %.

Die Änderungen betrafen hauptsächlich Infrastrukturarbeiten. Wir haben einige Datenbankabfragen bereinigt, die im Laufe der Zeit ineffizient geworden waren, und statische Assets hinter AWS CloudFront für das Edge-Caching platziert. Nichts bahnbrechendes, aber die Art von Arbeit, die sich auszahlt.

Wenn Sie Signaturen in Ihr Produkt einbetten, ist das wichtiger, als es scheint. 300 ms Latenz klingen nicht nach viel, aber es ist der Unterschied zwischen einem Signaturablauf, der sich sofortig anfühlt, und einem, der sich träge anfühlt. Schnellere Antworten bedeuten weniger abgebrochene Abläufe und weniger Reibung für Ihre Benutzer.

Einmalige Signaturanfragen (Kein Template Erforderlich)

Früher, wenn Sie ein Dokument zur Signatur über Firma.dev senden wollten, mussten Sie zuerst eine Vorlage erstellen. Das machte bei wiederverwendbaren Workflows wie Arbeitsverträgen oder NDAs Sinn, fügte jedoch unnötige Schritte für einmalige Dokumente hinzu.

Jetzt können Sie die Vorlage komplett überspringen. Laden Sie ein PDF direkt hoch, definieren Sie Ihre Felder und Empfänger in einem Schritt und senden Sie es. Ein API-Aufruf, keine Vorlagenerstellung erforderlich.

Dies ist nützlich für Ad-hoc-Vereinbarungen, einmalige Verträge oder jede Situation, in der Sie die Dokumentstruktur nicht wiederverwenden möchten. Sie haben immer noch alle gleichen Feldtypen, Unterzeichneroptionen und Tracking. Sie müssen nur keine Vorlage mehr einrichten.

Sehen Sie sich das Create Signing Request Endpoint für Implementierungsdetails an.

Atomarer Create + Send Endpoint

Apropos Reduzierung von API-Aufrufen: Wir haben einen neuen atomaren Endpoint hinzugefügt, der es Ihnen ermöglicht, eine Signaturanfrage in einem einzigen Aufruf zu erstellen und zu senden.

Bisher riefen Sie das Create-Endpoint auf und dann das Send-Endpoint. Zwei Anfragen, zwei Round-Trips. Das neue /signing-requests/create-and-send Endpoint kombiniert beides in einem.

Der wirkliche Vorteil ist jedoch die transaktionale Integrität. Das Endpoint validiert alles, bevor es etwas erstellt. Wenn etwas die Validierung nicht besteht, wird nichts erstellt und es werden keine Gebühren berechnet. Gutschriften werden nur abgezogen, nachdem die Signaturanfrage erfolgreich erstellt wurde und die E-Mails versendet wurden.

Aus den Docs: "Einzelner API-Aufruf statt zwei separater Anfragen... Atomares Kreditabbuchung – Belastet nur bei erfolgreicher Ausführung."

Wenn Sie Automatisierungen oder hochvolumige Workflows entwickeln, ist dieses Endpoint sauberer und zuverlässiger als das Verketten von zwei Aufrufen.

Nur-Lese-Felder

Sie können jetzt Felder als Nur-Lese markieren, wenn Sie eine Signaturanfrage erstellen oder aktualisieren. Diese sind Felder, die mit vorausgefüllten Werten im Dokument angezeigt werden, die der Unterzeichner jedoch nicht bearbeiten kann.

Dies ist nützlich für Dinge wie Vertragsbeträge, Referenznummern, berechnete Summen oder Mitarbeiter-IDs. Alles, was der Unterzeichner zur Orientierung sehen muss, aber nicht ändern darf.

Sie finden die read_only Eigenschaft im Comprehensive Update Endpoint. Setzen Sie es auf true auf einem beliebigen Textfeld, und es wird sichtbar, aber nicht bearbeitbar.

Granulare E-Mail-Kontrollen

Wir haben vier neue Einstellungen hinzugefügt, die Ihnen eine präzise Kontrolle darüber geben, welche E-Mails Firma.dev in Ihrem Namen sendet:

• send_signing_email – die initiale "Bitte unterschreiben Sie dieses Dokument"-Benachrichtigung

• send_finish_email – die "Unterschrift abgeschlossen"-Bestätigung

• send_expiration_email – die Erinnerung, wenn eine Anfrage kurz vor dem Ablauf steht

• send_cancellation_email – die Benachrichtigung, wenn eine Anfrage storniert wird

Alle vier sind standardmäßig auf true gesetzt, sodass bestehende Integrationen genau wie zuvor funktionieren. Aber wenn Sie Ihre eigenen gebrandeten E-Mails anstelle unserer senden möchten, können Sie jetzt eines oder alle davon ausschalten und Benachrichtigungen selbst verwalten.

Das passt gut zu den unten stehenden White-Label-Einstellungen.

Firma.dev AGB überspringen für Vollständige White-Labeling

Es gibt eine neue Einstellung in Ihrem Arbeitsplatz namens "Erforderliche Annahme der Bedingungen." Wenn sie aktiviert ist (Standard), müssen Unterzeichner die Bedingungen und Konditionen von Firma.dev akzeptieren, bevor sie unterschreiben. Wenn Sie es deaktivieren, entfällt dieser Schritt vollständig.

Dies ist für Teams konzipiert, die eine vollständig gebrandete Signaturerfahrung wünschen. Ihre Unterzeichner sehen Ihr Branding, Ihre E-Mails (wenn Sie unsere ausgeschaltet haben) und Ihre Bedingungen. Firma.dev bleibt unsichtbar.

Wenn Sie diesen Weg gehen, empfehlen wir, Ihre eigenen Bedingungen und Konditionen vorhanden zu haben. Sie übernehmen die Verantwortung, die Unterzeichner über die rechtlichen Auswirkungen ihrer Unterschrift zu informieren, stellen Sie also sicher, dass Ihre eigenen AGB dies abdecken.

In Kombination mit den oben genannten E-Mail-Kontrollen können Sie jetzt eine völlig gebrandete Signaturerfahrung bereitstellen, ohne dass die Firma.dev-Benutzeroberfläche für Ihre Endbenutzer sichtbar ist.

Neue Entwicklerhandbücher

Wir haben diesen Monat einen Teil unserer Dokumentation neu geschrieben. Drei neue Anleitungen sind online:

Authentifizierungsleitfaden – Behandelt die API-Schlüssel-Authentifizierung für serverseitige Anfragen sowie JWT-Token zum Einbetten der Vorlagen- und Signaturanfrage-Editoren in Ihre App. Umfasst auch den neuen API-Schlüssel-Rotationsablauf mit 24-Stunden-Toleranzzeiten.

Rate Limits Leitfaden – Dokumentiert alle Rate-Limit-Stufen (200 Anfragen/Min für Leseoperationen, 120/Min für Schreiboperationen usw.). Wichtige Anmerkung hier: Rate-Limits gelten pro Arbeitsplatz, und Sie können unbegrenzt viele Arbeitsplätze auf Ihrem Konto haben. Das bietet Ihnen de facto unbegrenzte horizontale Skalierbarkeit. Wenn Sie für einen speziellen Anwendungsfall dennoch höhere Limits benötigen, wenden Sie sich an den Support, und wir können sie erhöhen, aber die Standard-Limits sind bereits für sehr hohe Volumen ausgelegt.

Kompletter Einrichtungsleitfaden – Ein vollständiger Durchgang von der Kontoerstellung bis zur eingebetteten Unterschrift. Behandelt Workspaces, Vorlagen, Signaturanfragen, eingebettete Editoren, Webhooks und Kreditmanagement. Wenn Sie gerade erst anfangen, ist dies der richtige Ort.

Vollständige API-Versionierung

Wir haben diesen Monat ein formales Versionierungssystem eingeführt. Die API verwendet nun headerbasierte Versionierung über den X-API-Version Header, und wir sind derzeit bei v1.2.0.

Die Kurzversion: Wir verpflichten uns, Ihre Integration nicht zu unterbrechen. Aus dem Versionierungsleitfaden: "Breaking Changes werden nur in major Versionen eingeführt... Nicht-breaking changes wie neue optionale Felder oder neue Endpunkte erfordern keine neue Version."

Wenn wir irgendwann v2 herausbringen, wird die alte Version nicht einfach verschwinden. Sie erhalten zumindest sechs Monate lang Deprecation-Warnungen in den Antwort-Headern, bevor alles eingestellt wird. Die Header folgen RFC 8594, sodass Sie, wenn Sie bereits auf Deprecation und Sunset Header bei anderen APIs achten, wissen, was Sie erwartet.

Für den Moment ist v1 aktiv und keine Deprecation geplant. Alles, was wir in diesem Monat ausgeliefert haben, ist ergänzend, sodass Ihre bestehende Integration ohne Änderungen weiter funktioniert.

Zusammenfassung

Das war der Januar. Viele kleine bis mittlere Verbesserungen, die zusammen eine fähigere, flexiblere API ergeben.

Preise haben sich nicht geändert. Es kostet immer noch €0,029 pro Umschlag, Pay-as-you-go, ohne Mindestanforderungen. Wenn Sie Firma.dev noch nicht ausprobiert haben, erhalten Sie 25 kostenlose Umschläge zum Testen.

Wir werden weiterhin liefern. Wenn es etwas gibt, das Sie in der API sehen möchten, lassen Sie es uns wissen.

Kostenlos loslegen – keine Kreditkarte erforderlich.