Änderungsprotokoll

Änderungen der API innerhalb von /v1 sind additiv: neue Endpunkte, neue optionale Felder, neue Antwortfelder, neue Fehlercodes und neue Ereignistypen. Alles, was einen Client brechen könnte, erscheint in einer neuen Version und wird zuerst hier angekündigt.

25. Oktober 2026: Pakete 0.3.20

• n8n-Node: Eine abgelehnte Anfrage nennt ihr Feld und ihre Regel, im Fehler des Nodes und an seinem Fehlerausgang (siehe 24. Oktober).
• Plugin für Coding-Agenten: formfeed-dev/skills enthält auch die Dateien, die Codex, GitHub Copilot, die Gemini CLI und Antigravity lesen, jede mit dem gehosteten MCP-Server in den Worten des jeweiligen Agenten.
• Die übrigen Pakete gehen ohne eigene Änderungen auf 0.3.20.

24. Oktober 2026: der n8n-Node sagt, warum eine Anfrage abgelehnt wurde

• n8n-Node: n8n-nodes-formfeed 0.3.20 zeigt bei einer abgelehnten Anfrage den Satz der API, der das Feld und die verletzte Regel nennt, statt des Satzes von n8n zum Statuscode („Your request is invalid or could not be processed by the service“). Mit Continue (using error output) trägt das Item am Fehlerausgang diesen Satz als error und die ganze Antwort der API als details, sodass eine abgelehnte E-Rechnung jeden Befund mit path und rule auflistet (siehe n8n). Bisher nannte der Fehlerausgang nur den Satz von n8n.

22. Oktober 2026: der n8n-Node ist verifiziert

• n8n: n8n hat n8n-nodes-formfeed verifiziert, deshalb bietet ihn neben selbst gehostetem n8n auch n8n Cloud an: Öffnen Sie das Nodes-Panel, suchen Sie nach Formfeed und klicken Sie auf Install node (Owner und Admins; siehe n8n). Die Installation über den Paketnamen funktioniert in einem selbst gehosteten n8n weiterhin. Ein aktuelles n8n bietet den Node seinem AI Agent ohne die Einstellung N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE als Tool an, die ältere selbst gehostete Versionen brauchten.

21. Oktober 2026: Pakete 0.3.19

• SDKs: Die Typen von @formfeed/sdk und dem Python-Paket formfeed kennen period_start, period_end und hard_cap_units der Nutzung, die die API schon immer sendet (siehe 20. Oktober). In TypeScript sind data_sets und partials einer Version nicht mehr null, was die API nie sendet, und beide SDKs nennen den Bereich von rotation eines Wasserzeichens und sagen, dass ein Bild ohne sie aufrecht steht.
• Vorlagen-Engine: renderVersion von @formfeed/engine rendert pdf.metadata.author, subject und keywords mit den Daten, wie es Renderings seit dem 19. Oktober tun, und gibt sie als metadata zurück; ein Feld, das leer gerendert wird, entfällt.
• Plugin für Coding-Agenten: Das Plugin in formfeed-dev/skills bringt neben dem gehosteten MCP-Server zwei Skills: formfeed-templates schreibt und prüft Vorlagen in einem Projekt mit der Kommandozeile, formfeed-api schreibt den Code, der über die API rendert. Beide sagen es, bevor ein Rendering mit einem Live-Schlüssel Einheiten kostet, und ändern den Workspace nur auf Wunsch. Claude Code installiert es als Plugin; jeder Agent, der Agent Skills liest, übernimmt die Skills mit npx skills add formfeed-dev/skills. Siehe Coding-Agenten.

21. Oktober 2026: der Power-Automate-Connector ist verfügbar

• Power Automate: Der Formfeed-Connector, den Microsoft am 5. Oktober zertifiziert hat, ist in den Umgebungen angekommen: Fügen Sie in Power Automate, Power Apps oder Copilot Studio eine Aktion oder Verbindung hinzu und suchen Sie nach Formfeed, Herausgeber Formfeed, markiert als Preview. Wo er nicht angeboten wird, stellt die HTTP-Aktion denselben Aufruf. Siehe Power Automate.

21. Oktober 2026: Schlüssel, Endpunkte und Mitglieder im Suchfeld

• App: Das Suchfeld auf Strg+K findet API-Schlüssel nach Name und Präfix, Webhook-Endpunkte nach Adresse und die Mitglieder der Organisation nach Name und E-Mail, für Inhaber und Admins auch ihre offenen Einladungen. Ein eingefügter API-Schlüssel findet den Schlüssel, zu dem er gehört, an seinen ersten Zeichen, nur im Browser. → auf einer Vorlage zeigt ihre Aktionen (sie öffnen, ihr API-Tab, ihre Renderings, Slug oder ID kopieren), ← führt zurück. Inhaber und Admins finden dort auch API-Schlüssel anlegen, Webhook-Endpunkt hinzufügen und Mitglieder einladen. Siehe den Editor-Rundgang.
• Geändert: Vorlagen-ID kopieren in der Vorlagenliste kopiert die ID, die die API zeigt (tpl_…), statt der bloßen UUID. Die API nimmt beide, und das Suchfeld öffnet eine eingefügte ID tpl_… als Vorlage.

21. Oktober 2026: Ein Batch behält die Reihenfolge seiner Einträge

• Behoben: GET /jobs/{id}, das Ereignis job.completed und das Zip eines Batches listen dessen Einträge in der Reihenfolge der Anfrage, wie dokumentiert. Bisher listeten sie sie in der Reihenfolge, in der die Renderings fertig wurden, und die weicht ab, sobald Einträge außer der Reihe fertig werden (Renderings laufen nebeneinander, Dokumente sind unterschiedlich lang, ein wiederholter Eintrag wird zuletzt fertig): items[2] konnte das Dokument einer anderen Zeile sein und 0003-document.pdf die Datei eines anderen Eintrags. Die Dateien eines Zips sind jetzt nach der Position ihres Eintrags in der Anfrage nummeriert, und ein fehlgeschlagener Eintrag lässt seine Nummer aus. Batches, die vor dieser Korrektur gesendet wurden, behalten ihre bisherige Reihenfolge. Siehe Asynchron und Batch.

21. Oktober 2026: ein fehlgeschlagenes Rendering im apitemplate.io-Shim und die Berechtigungen eines Passworts

• Behoben: Ein Fehler des apitemplate.io-Shims zu einem Rendering, das vor seinem Scheitern aufgezeichnet wurde, trägt die ID des Renderings als transaction_ref, wie es der Fehler eines noch laufenden Renderings schon tat. Fehler in der Vorlage und Seitenlimits kamen ohne sie zurück, sodass sich das fehlgeschlagene Rendering nicht nachschlagen ließ.
• Behoben: Ein Rendering mit post.password ohne permissions wird mit den vier Berechtigungen aufgezeichnet, die sein PDF erlaubt (print, copy, modify, annotate). Bisher wurde es mit keiner aufgezeichnet, was [] bedeutet, sodass die Optionen des Renderings in der App sagten, Leser dürften nichts. Die PDFs selbst waren richtig.

21. Oktober 2026: vier Antworten, die weniger sagten, als sie sollten

• Geändert: POST /webhooks/{id}/test für einen deaktivierten Endpunkt antwortet mit 409 conflict. Bisher antwortete er mit 202, und es kam nichts an, weil ein deaktivierter Endpunkt keine Zustellungen empfängt. Siehe Webhooks.
• Behoben: Eine wiederholte Anfrage mit demselben Idempotency-Key trägt wieder Location, Retry-After, X-Units-* und X-Render-* der ersten Antwort, nicht nur ihren Body, sodass ein Client, der der Location eines 202 folgt, auch einer wiederholten folgen kann. Siehe Idempotenz.
• Behoben: Ein PDF-Tool, das nach seiner Aufzeichnung fehlschlägt, nennt sein Rendering als render_id im Problem, wie ein fehlgeschlagenes Rendering; das Render-Protokoll und GET /renders/{id} zeigen es.
• Behoben: POST /pdf/watermark mit einem Bild prüft Scope und Plan des Schlüssels, bevor es das Bild in der Bibliothek sucht, sodass ein Schlüssel, der das Tool nicht nutzen darf, 403 forbidden hört und nie, ob die Bibliothek eine Datei dieses Namens hat.

21. Oktober 2026: Das Render-Protokoll behält 13 Monate

• Geändert: Einträge im Render-Protokoll werden 13 Monate aufbewahrt. Einmal im Monat werden ältere Einträge mit ihren Batch-Jobs gelöscht, jeder, sobald seine Dateien gelöscht sind: Ein Eintrag, dessen Datei noch gespeichert ist, bleibt so lange wie die Datei. GET /renders/{id} und GET /jobs/{id} antworten für Gelöschtes mit 404, und GET /usage behält die Summen jedes Abrechnungszeitraums, nennt die Tage und Vorlagen eines Zeitraums aber nur, solange seine Einträge existieren. Bisher blieben Einträge, bis der Workspace gelöscht wurde; die ältesten werden im Oktober 2027 13 Monate alt. Siehe Datenresidenz.

20. Oktober 2026: Slugs aus zwei Zeichen

• Behoben: Ein Slug aus zwei Zeichen, etwa de oder q4, wird für Vorlagen, Organisationen und Workspaces angenommen. Die Regel nahm ein Zeichen oder drei und mehr, aber nie zwei, in der API, in der App und in der Datenbank gleichermaßen. Slugs sind bei Vorlagen 1 bis 64 Zeichen lang und bei Organisationen und Workspaces 1 bis 40, Kleinbuchstaben, Ziffern und Bindestriche, beginnend und endend mit einem Buchstaben oder einer Ziffer. Siehe Vorlagen.

20. Oktober 2026: Der API-Vertrag sagt, was die API tut

• Geändert: Die API-Referenz und /v1/openapi.json beschreiben jetzt jedes Feld, jeden Header und jeden Statuscode, den die API sendet. Der error eines Renderings hat ein eigenes Schema (code, message und was mehr sagt), nicht mehr das eines Problems; ein Rendering, ein Job, ein Account und die Nutzung nennen jeden Schlüssel, den sie immer tragen; die Probleme nennen ihre Felder mit den Codes, mit denen sie kommen; die binäre Antwort von output=binary nennt alle sechs Dateitypen und ihre Header; und die Antworten des apitemplate.io-Shims, sein 302 und seine Fehler in der Form von apitemplate.io sind beschrieben, wie sie sind. Die Antworten selbst ändern sich nur, wo ein Punkt unten es sagt.
• Behoben: POST /templates behält data_sets, die benannten Beispieldatensätze, in der ersten Version. Bisher fielen sie weg, und formfeed templates push verlor sie bei einer neuen Vorlage.
• Behoben: Das Veröffentlichen einer Version einer Word- oder PowerPoint-Vorlage (POST /templates/{id}/versions/{number}/publish) antwortete mit dem internen Speicherschlüssel der Datei, den keine andere Antwort zeigt. Er ist aus der Antwort verschwunden.
• Behoben: Ein cursor, den keine Seite der Liste ausgegeben hat, ergibt bei GET /renders, /templates und /files 400 invalid_request statt 500; ebenso GET /usage?period= mit einem Monat, den es nicht gibt, und Werte von output_image_type, die der apitemplate.io-Shim nicht kennt. Der Shim nimmt jetzt auch jpegOnly und pngOnly von apitemplate.io und antwortet mit JSON, wenn seine URL output=binary trägt, statt nach dem Rendering mit 500.
• Behoben: Eine 36 Zeichen lange ID, die keine UUID ist, ergibt bei den Webhook-Routen 404 statt 500; die ID einer formfeed listen-Sitzung ist DELETE /webhooks/{id} und POST /webhooks/{id}/test unbekannt, wie schon der Liste und PUT (eine Sitzung endet mit DELETE /webhooks/listen/{id}); und POST /webhooks antwortet immer mit environments.
• Geändert: Das 202 von POST /renders/batch nennt den Job in Location als absolute URL, wie das 202 eines Renderings, mit Retry-After: 5. Ein rate_limited-Problem der Minute eines Testschlüssels im Free-Plan sagt window_seconds: 60 statt 1.

19. Oktober 2026: Metadaten aus den Daten, ein Zeitlimit fürs Drucken, Bilder, die sich öffnen

• Geändert: In einem Rendering einer Vorlage werden pdf.metadata.author, subject und keywords wie der Titel mit den Daten gerendert; eines, das leer gerendert wird, entfällt. Bisher kamen sie so ins PDF, wie sie geschrieben waren, mit Vorlagensyntax und allem. Siehe die Einstellungen.
• Geändert: Das Drucken eines PDF hat ein Zeitlimit, 120 Sekunden; ein Druck, der länger dauert, scheitert mit 504 render_timeout. Bisher hatte das Drucken keines. Ein Dokument von mehreren hundert Seiten druckt in einigen zehn Sekunden.
• Geändert: Ein gerendertes Bild (PNG, JPG, WebP) öffnet sich unter seinem Dateinamen im Browser, wenn sein Link geöffnet wird, statt heruntergeladen zu werden; das gilt auch für früher gerenderte Bilder. PDFs und Office-Dateien werden weiter heruntergeladen, und download=1 am Link macht auch ein Bild zum Download. Siehe Dateiname.

19. Oktober 2026: Pakete 0.3.18

• MCP-Server: @formfeed/mcp 0.3.18 liefert das Bild eines Bild-Renderings neben seinem Link und startet ohne FORMFEED_API_KEY mit den Offline-Prüfungen (siehe unten), und jedes Tool sagt, was es zurückgibt (outputSchema), sodass ein Client das strukturierte Ergebnis prüfen kann. Der Eintrag in der MCP-Registry verlangt den Schlüssel nicht mehr.
• Vorlagen-Engine und Kommandozeile: @formfeed/engine und formfeed bringen den neuen Standard waitFor.networkIdle: "auto" und markieren die Skripte der Engine mit data-formfeed (siehe 18. Oktober), sodass sich ein Snapshot von formfeed test einer Vorlage mit angepasstem Text um dieses Attribut ändert: Bestätigen Sie ihn mit formfeed test -u neu. formfeed dev bricht Tabellen in seiner Seitenvorschau um wie das PDF (siehe 18. Oktober), formfeed ci preview nennt den Schlüssel, mit dem gerendert wurde, und die Hilfe von --base-url, --workspace, --ci und --verbose sagt, was jede Option wirklich tut. Die Beispiele des Helpers epcQr setzen die Rechnungsnummer in text, den Verwendungszweck.
• n8n-Node: n8n-nodes-formfeed 0.3.18 sagt, dass nur der Free-Plan Test-Renderings markiert, und erwähnt kein selbst gehostetes Gateway mehr.

19. Oktober 2026: Agenten sehen die Bilder, die sie rendern

• MCP-Server: render und get_render liefern das Bild eines Bild-Renderings (PNG, JPG oder WebP, bis 2 MB) neben seinem Link, damit ein Agent ansehen kann, was er erzeugt hat, bevor er es weitergibt. Ein PDF kommt weiter als Link. Der gehostete Server unter mcp.formfeed.dev hat das jetzt, @formfeed/mcp mit dem nächsten Release der Pakete. Siehe MCP-Server.
• MCP-Server: Der lokale Server startet auch ohne FORMFEED_API_KEY. Dann funktionieren validate_template mit html und check_invoice offline, und jedes andere Tool antwortet, wie man einen Schlüssel bekommt, sodass ein Agent die Prüfungen ausprobieren kann, bevor sich jemand registriert. Mit dem nächsten Release der Pakete.
• Kommandozeile: Die Zusammenfassung von formfeed ci preview nennt den Schlüssel, mit dem gerendert wurde: Bisher stand dort „Test-Schlüssel“ auch unter Renderings eines Live-Schlüssels, die Einheiten gezählt hatten. Mit dem nächsten Release der Pakete.
• Behoben: Die Hilfe des MCP-Servers, die n8n-Zugangsdaten und die Zapier-Verbindung sagten, ein Test-Schlüssel setze immer ein Wasserzeichen; nur der Free-Plan markiert Test-Renderings. Die n8n- und Make-Verbindungen erwähnen kein selbst gehostetes Gateway mehr, das es nicht gibt.

18. Oktober 2026: Die Seitenvorschau bricht Tabellen um wie das PDF

• Editor: Eine Tabelle, die über mehrere Seiten läuft, bekommt in der Vorschau Seiten ihren Tabellenkopf oben auf jeder Seite wieder und ihren tfoot unten auf jeder Seite, auf der sie weitergeht, mit dem Platz dafür, so wie Chromium sie druckt. Bisher ließ die Vorschau beides weg: Seite 2 einer Rechnung hatte keinen Tabellenkopf, ihre Zeilen verschoben sich gegenüber dem PDF um eine pro Seite, und bei 120 Positionen zeigte die Vorschau fünf Seiten, wo das PDF sechs hat. Ein Tabellenkopf ohne Zeile darunter am Fuß einer Seite wandert jetzt mit seiner Tabelle weiter, eine Zeile, die höher ist als der Rest der Seite, bricht unter dem wiederholten Kopf um, statt weiterzuwandern, und ein Element mit position: fixed steht, wo Chromium es druckt, innerhalb der Seitenränder. Die 21 Tabellen aus Seitenumbrüche in Tabellen kommen Seite für Seite heraus wie ihre PDFs, und ein Test hält sie dort.
• Kommandozeile: formfeed dev zeigt dasselbe mit der nächsten Version der Pakete.

18. Oktober 2026: Renderings ohne die halbe Sekunde Wartezeit

• Geändert: Ein Dokument wird gedruckt, sobald es geladen ist, keine seiner Anfragen mehr läuft und seine Schriften bereit sind. Bisher wartete jedes Rendering außerdem, bis das Netzwerk eine halbe Sekunde geruht hatte, was bei einem einfachen Dokument den größten Teil seiner Renderzeit ausmachte. Ein url-Rendering und eine Vorlage mit einem eigenen Skript, einem Event-Handler-Attribut oder einem Frame warten weiter diese halbe Sekunde, weil ihr Code später noch eine Anfrage starten kann; die Skripte, die Formfeed für Diagramme und angepassten Text einfügt, zählen nicht. Das ist der neue Standard von waitFor.networkIdle, "auto"; true behält die alte Wartezeit für eine Vorlage, die sie braucht, false bleibt, wie es war.
• Vorlagen-Engine: Die Skripte, die @formfeed/engine in ein Dokument schreibt, tragen data-formfeed, wie ihre Styles. Ein Snapshot von formfeed test einer Vorlage mit angepasstem Text (data-ff-fit) ändert sich um dieses Attribut; bestätigen Sie ihn mit formfeed test -u neu.

18. Oktober 2026: Datei-IDs als Quellen, Zips, die ablaufen, die Webhook-Endpunkte eines Plans

• Behoben: Die ID einer Datei der Bibliothek (fil_…) funktioniert jetzt als Quelle eines Merges (post.merge_after, /pdf/merge) und als image eines Wasserzeichens, wie es die Typen der SDKs schon immer sagten. Bisher ging nur der Name der Datei, und eine ID ergab 422 source_not_found. Siehe PDF-Tools.
• Geändert: Das Zip eines Batches wird gelöscht, wenn die erste Datei darin abläuft, sodass kein Dokument in einem Zip länger bleibt als seine eigene Aufbewahrungsfrist. Bisher blieb ein Zip, bis sein Workspace gelöscht wurde. Früher erstellte Zips folgen derselben Regel, und eines, dessen erste Datei schon abgelaufen ist, wird jetzt gelöscht. Siehe Aufbewahrung und Löschung.
• Geändert: Die Anzahl der Webhook-Endpunkte, die ein Plan enthält, wird durchgesetzt: einer im Free-Plan, fünf im Starter-Plan, beliebig viele ab Pro, gezählt pro Organisation. Ein weiterer ergibt 403 forbidden mit feature: "webhooks" und dem limit; Endpunkte, die über die Anzahl hinaus schon bestehen, bleiben. Ein eingeschalteter Trigger eines No-Code-Tools ist ebenfalls ein Endpunkt, eine Sitzung von formfeed listen nicht.
• Geändert: Die größte Ausgabe im Enterprise-Plan ist 250 MB, die Größe, an die jedes Rendering gebunden ist; der Plan nannte 1.000 MB, die kein Rendering erreichen konnte.

15. Oktober 2026: ein Suchfeld auf Strg+K

• App: Strg+K (⌘K auf dem Mac) findet Ihre Vorlagen, die Beispiele, geteilte Partials, Dateien, die Seiten der App und die Abschnitte von Einstellungen, Abrechnung und Marke sowie die wichtigsten Seiten der Dokumentation, neben den Befehlen der Seite, auf der Sie sind. Der passende Teil jedes Treffers ist hervorgehoben, die Wörter dürfen in beliebiger Reihenfolge stehen, Umlaute müssen nicht getippt werden. #, >, / und ? grenzen die Suche auf Vorlagen, Befehle, Seiten oder die Hilfe ein; eine eingefügte ID rnd_… oder tpl_… öffnet dieses Rendering oder diese Vorlage. Siehe den Editor-Rundgang.

12. Oktober 2026: Pakete 0.3.17

• n8n-Node: n8n-nodes-formfeed 0.3.17 bringt Render → Create E-Invoice (siehe 9. Oktober). Seine README führt Schritt für Schritt durch einen Workflow: eine Rechnung, gerendert aus dem Beispiel der Galerie und per E-Mail verschickt, und was der Trigger einem Workflow übergibt, wenn ein Render fertig ist.
• MCP-Server: @formfeed/mcp 0.3.17 bringt check_invoice und die Option einvoice von render. Mit --http beantwortet er auch die Server-Card unter /mcp/server-card, wie es der gehostete Endpunkt tut.
• Vorlagen-Engine und Kommandozeile: @formfeed/engine und formfeed prüfen eine Rechnung zwischen zwei französischen Unternehmen nach Frankreichs Regeln (siehe 9. Oktober), und die Engine exportiert die Liste der Geschäftsbegriffe als EN16931_TERMS.
• SDKs: Die Typen von @formfeed/sdk und dem Python-Paket formfeed kennen die neuen Felder des Berichts, id, versions, xml_sha256 und pdf_sha256 (siehe 9. Oktober).

11. Oktober 2026: eine GitHub Action für Vorlagen

• GitHub Action: Formfeed templates im GitHub Marketplace führt die Kommandozeile in einem Workflow aus: validate und test bei jedem Lauf, die Vorlagen, die ein Pull Request ändert, zur Prüfung gerendert, mit der Zusammenfassung als einem Kommentar, den jeder Lauf aktualisiert, und das Veröffentlichen vom Standard-Branch. Einzubinden als formfeed-dev/formfeed-action@v1. Siehe GitHub Actions.

11. Oktober 2026: E-Rechnungen aus WooCommerce

• Dokumentation: WooCommerce macht jede fertiggestellte Bestellung zur ZUGFeRD- / Factur-X-E-Rechnung: eine Funktion, die die Bestellung der REST-API von WooCommerce dem _invoice-Block zuordnet, mit Produkten, Versand und Gebühren als Positionen, Gutscheinen als Nachlässen und der Umsatzsteuer je Satz, wie die Bestellung sie nennt; die Konfiguration, die sie braucht (wer Sie sind, wo Ihr USt-IdNr.-Plugin die des Käufers speichert, die Kategorie eines Satzes von 0 % und eines Kunden, den WooCommerce von der Umsatzsteuer befreit, wann eine offene Rechnung fällig ist); ein Webhook-Handler, der die Signatur von WooCommerce prüft und jede Bestellung nur einmal verarbeitet; und dasselbe in n8n. Wie beim Stripe-Rezept läuft der Code der Seite gegen Bestellungen, wie die API von WooCommerce sie liefert, und durch die Prüfung, die die API vor dem Rendern einer E-Rechnung ausführt.

11. Oktober 2026: E-Rechnungen aus Stripe

• Dokumentation: Stripe macht jede Rechnung, die Stripe finalisiert, zur ZUGFeRD- / Factur-X-E-Rechnung: eine Funktion, die Stripes Rechnung dem _invoice-Block zuordnet, die Konfiguration, die sie braucht (wer Sie sind und welche Umsatzsteuerkategorie Stripes Steuergründe und Steuersätze haben), ein Webhook-Handler für invoice.finalized und dasselbe in n8n. Die Funktion übernimmt Stripes Beträge, zeigt Rabatte als Nachlässe und Gutschriften als negative Mengen und lehnt ab, was sie nicht abbilden kann, etwa Versandkosten oder einen Grund ohne Kategorie, statt zu raten. Der Code der Seite läuft gegen Rechnungen, wie Stripes API sie liefert, und durch die Prüfung, die die API vor dem Rendern einer E-Rechnung ausführt.

10. Oktober 2026: Test-E-Rechnungen tragen in jedem Plan die Testmarkierung

• Geändert: Ein Test-Rendering, das eine E-Rechnung erzeugt, trägt in jedem Plan die Testmarkierung, und die bezahlten Pläne zählen sie pro Organisation und Tag wie der Free-Plan: bis zu 100 pro Tag im Starter-Plan, 500 im Pro-Plan und 2.000 im Business-Plan, ein Dreißigstel der monatlichen Einheiten des Plans; Enterprise nach Vertrag. Bisher waren die Test-E-Rechnungen eines bezahlten Plans weder markiert noch gezählt, gültige Rechnungen, die keine Einheit kosteten. Sobald der Tag aufgebraucht ist, beantwortet die API eine Test-E-Rechnung mit 403 forbidden und limit, used und resets_at. Das echte Rendering einer Rechnungsvorlage im Editor und Testanfrage senden in seinem API-Tab sind ebenfalls Test-Renderings. Test-Renderings anderer Dokumente bleiben in den bezahlten Plänen ohne Markierung, und Live-Renderings werden weder gezählt noch markiert. Siehe Limits und Verbrauch.

10. Oktober 2026: E-Rechnungen aus Zapier

• Zapier: Die neue Aktion Create E-Invoice erzeugt eine ZUGFeRD- / Factur-X-E-Rechnung aus Feldern für die Rechnung selbst, gruppiert nach Rechnung, Verkäufer, Käufer, Positionen und Umsatzsteuer, Summen und Zahlung. Positionen und Aufschlüsselung der Umsatzsteuer sind Line Items, die Line Items eines Triggers werden also Zeile für Zeile zugeordnet. Eine abgelehnte Rechnung nennt im Fehler des Zaps jedes Feld und jede Regel, und die Ausgabe trägt den Bericht des Validators. Sie kommt mit Version 0.2.0 der Zapier-App. Siehe Zapier.

9. Oktober 2026: E-Rechnungen aus n8n und von KI-Agenten

• n8n-Node: Render → Create E-Invoice erzeugt eine ZUGFeRD- / Factur-X-E-Rechnung aus den Feldern der Rechnung (Verkäufer, Käufer, Positionen, Aufschlüsselung der Umsatzsteuer, Summen, Zahlung), die der Node als _invoice-Block an eine Vorlage sendet, die ihn druckt, etwa das Beispiel „E-Rechnung“ der Galerie. Was die Felder nicht anbieten, gehört in ein JSON-Feld, und die Ausgabe des Nodes trägt den Bericht des Validators. Siehe n8n.
• MCP-Server: Das neue Tool check_invoice prüft einen _invoice-Block offline, wie die API es vor dem Rendern tut, und render nimmt einvoice, um aus dem PDF eine E-Rechnung zu machen. Eine abgelehnte Rechnung kommt als Werkzeugfehler zurück, der jedes Feld und jede Regel nennt, sodass der Agent den Block korrigieren kann. Siehe MCP-Server.
• Der gehostete Endpunkt mcp.formfeed.dev hat beides jetzt; @formfeed/mcp und n8n-nodes-formfeed bringen es mit der nächsten Paketversion.

9. Oktober 2026: Der Bericht der E-Rechnung nennt, was welche Datei geprüft hat

• API: Der Bericht einer E-Rechnung, einvoice.validation, trägt jetzt auch die Kennung des Validators für den Bericht (id), die Versionen seiner Teile (versions: Mustang, veraPDF, PDFBox) und SHA-256 des geprüften XML und PDF, xml_sha256 und pdf_sha256. Bei einem erfolgreichen Rendering ist pdf_sha256 die ausgelieferte Datei und gleich output_sha256 des Renderings. Berichte früherer Renderings bleiben, wie sie waren. Siehe Was zurückkommt.
• Dokumentation: Abdeckung der E-Rechnung nennt die 129 der 164 Geschäftsbegriffe der EN 16931, die der _invoice-Block trägt, mit dem Feld, aus dem jeder stammt, und die Versionen des Validators und seiner Regeln, erzeugt aus dem Code, der läuft. E-Rechnungen nach Ländern sagt, welches Land was verlangt, mit einer Quelle je Land, und wo der Teil von Formfeed endet.
• SDKs: Die Typen von @formfeed/sdk und des Python-Pakets formfeed kennen die neuen Felder ab der nächsten Paketversion, und @formfeed/engine exportiert die Liste der Geschäftsbegriffe als EN16931_TERMS.

9. Oktober 2026: Rechnungen zwischen französischen Unternehmen folgen Frankreichs Regeln

• Behoben: Eine E-Rechnung zwischen zwei französischen Unternehmen im Profil basic wird mit 422 einvoice_data_invalid abgelehnt. Frankreichs Reform nimmt nur die Profile EN 16931 und EXTENDED-CTC-FR an (AFNOR XP Z12-012); eine solche Datei war nach den europäischen Regeln gültig, aber keine, die eine französische Plattform annimmt. en16931, der Standard, bleibt unverändert.
• Behoben: operation_code nimmt jeden Abrechnungsrahmen an, den die französischen Regeln aufführen. S3 (öffentliche Auftraggeber) und die Rahmen für Rechnungen mehrerer Verkäufer, B8, S8 und M8, werden nicht mehr abgelehnt.
• Geändert: Eine solche Rechnung braucht außerdem die drei gesetzlichen Hinweise (PMT, PMD, AAB) und die elektronischen Adressen von Verkäufer und Käufer, die Frankreichs Regeln zur Pflicht machen (BR-FR-05, BR-FR-12, BR-FR-13). Bisher warnte der Validator nur, wenn eines davon fehlte, und die Datei wurde ausgeliefert; jetzt wird die Anfrage vor dem Rendering mit 422 einvoice_data_invalid abgelehnt.
• formfeed validate, formfeed einvoice und @formfeed/engine prüfen dasselbe ab der nächsten Paketversion.

9. Oktober 2026: Pakete 0.3.16

• Alle Pakete wechseln ohne eigene Änderungen zu 0.3.16. Die Version legt eine Kopie der Credential-Datei des n8n-Knotens ins Hauptverzeichnis des öffentlichen Repositorys, wo die Prüfung von Community-Nodes durch n8n sie sucht.

9. Oktober 2026: Pakete 0.3.15

• Vorlagen-Engine: @formfeed/engine 0.3.15 nimmt als Quelle einer Vorlage nur Text an (Body, Header, Footer, PDF-Titel und Partials) und verlangt Handlebars 4.7.10. Handlebars kompiliert ein Objekt als bereits geparsten Syntaxbaum, und bis 4.7.9 konnten Werte eines solchen Baums als Code laufen (GHSA-8r5x-fm3f-whwj).
• n8n-Knoten: n8n-nodes-formfeed 0.3.15 folgt den Regeln von n8n für verifizierte Community-Nodes: Auswahllisten in alphabetischer Reihenfolge, Get Many liefert ohne gesetztes Limit 50 Ergebnisse (bisher 25), der Standard-Kanal heißt Published, und Knoten und Zugangsdaten tragen Icons für helles und dunkles Design.
• formfeed (CLI und Python), @formfeed/sdk, @formfeed/devkit, @formfeed/testing, @formfeed/mcp und das Activepieces-Piece wechseln zu 0.3.15; CLI und MCP-Server bündeln die Engine und bringen ihre Änderung mit.

8. Oktober 2026: Die Aufbewahrung des Plans ist die Grenze, und Tailwind für einfaches HTML

• Behoben: Eine Ausgabe wird nicht mehr länger aufbewahrt als die Aufbewahrungsfrist des Plans. expires_in und die eigene Frist eines Workspace sollten sie verkürzen, ein längerer Wert setzte sich aber einfach durch; eine Anfrage konnte so in einem Plan mit 30 Tagen ein Jahr verlangen. Ein längeres expires_in wird jetzt auf die Aufbewahrungsfrist gekürzt, und eine längere Frist in den Einstellungen des Workspace gilt als die des Plans. Ausgaben, die vor dieser Änderung gerendert wurden, behalten ihr Ablaufdatum, und Pläne ohne Grenze (Business und höher) sind nicht betroffen.
• Behoben: "tailwind": true in den Einstellungen kompiliert die Tailwind-Klassen auch von Ad-hoc-html ohne engine. Bisher bekam nur HTML mit einer Engine das Stylesheet, einfaches HTML wurde ungestaltet gedruckt. Ein vollständiges Dokument bekommt das Stylesheet an den Anfang seines Head, vor seine eigenen Styles.

7. Oktober 2026: Pakete 0.3.14

• SDK: @formfeed/sdk 0.3.14 ruft fetch so auf, wie Browser und Cloudflare Workers es verlangen. Bisher scheiterte ein Client auf diesen Laufzeiten mit Illegal invocation an jeder Anfrage, sofern kein fetch übergeben wurde; Node war nie betroffen.
• MCP-Server: @formfeed/mcp 0.3.14 bringt das Tool get_workspace, und der gehostete Endpunkt https://mcp.formfeed.dev/mcp nimmt neben dem API-Schlüssel eine Anmeldung entgegen, der Workspace wird bei der Zustimmung gewählt. Der selbst betriebene --http-Server nimmt die Anmeldung auf /mcp ebenfalls an, sobald --auth-server gesetzt ist.
• formfeed (CLI und Python), @formfeed/engine, @formfeed/devkit, @formfeed/testing, der n8n-Knoten und das Activepieces-Piece wechseln ohne eigene Änderungen zu 0.3.14.

7. Oktober 2026: der gehostete MCP-Server beantwortet Tool-Aufrufe

• Behoben: Jeder Tool-Aufruf auf mcp.formfeed.dev scheiterte mit network_error: Illegal invocation, mit API-Schlüssel wie mit Anmeldung, seit der gehostete Endpunkt am 17. September live ging. Das TypeScript-SDK, auf dem der Endpunkt aufbaut, rief das globale fetch als Methode seines Clients auf, was Node akzeptiert und Browser wie Cloudflare Workers ablehnen. Der Endpunkt antwortet seit dem Deploy dieses Tages.
• SDK: Derselbe Fehler betraf @formfeed/sdk im Browser oder in einem Cloudflare Worker, wann immer kein fetch übergeben wurde. In den Quellen behoben; die nächste Paketversion bringt es mit. Bis dahin auf diesen Laufzeiten fetch: (input, init) => fetch(input, init) übergeben.

7. Oktober 2026: eine MCP-Adresse, der Workspace wird bei der Zustimmung gewählt

• MCP-Server: https://mcp.formfeed.dev/mcp nimmt neben dem API-Schlüssel auch eine Anmeldung entgegen. Ein Chat-Client öffnet die Formfeed-Anmeldung selbst, und die Zustimmungsseite fragt, in welchem Workspace der Agent arbeitet; die Wahl reist im Token des Agenten, und die API prüft die Mitgliedschaft wie bisher bei jedem Aufruf. https://mcp.formfeed.dev/mcp/<workspace id> funktioniert weiter und legt für eine zweite Verbindung einen anderen Workspace fest.
• MCP-Server: Das neue Tool get_workspace antwortet mit Workspace, Organisation, Tarif, Umgebung und den Einheiten des Zeitraums, wie GET /account, damit ein Agent sagen kann, wo ein Dokument landet und wie viele Renderings noch bleiben. Das Token eines Agenten darf jetzt das Konto lesen (account:read) und sonst nichts mehr als bisher.
• App: Konto → Verbundene Agenten listet jeden erlaubten Agenten mit seinem Workspace, der sich dort ändern lässt, und einem Widerruf, der den Agenten abmeldet. Ein vor dieser Änderung erlaubter Client wird beim nächsten Verbinden nach seinem Workspace gefragt.
• Geändert: POST /templates/{id}/validate und die anderen /v1-Routen antworten einem Agenten, für den noch kein Workspace gewählt ist, mit 403 und dem Grund, wo sie bisher wegen des fehlenden Headers X-Formfeed-Workspace mit 400 antworteten.

5. Oktober 2026: Pakete 0.3.13

• CLI: formfeed 0.3.13 arbeitet mit barrierefreien PDFs. Für eine Vorlage, deren settings.json pdf.ua festlegt, meldet formfeed validate, was die Quelle über die Datei schon sagt, etwa einen fehlenden Titel oder ein ohne alt geschriebenes Bild: als Fehler, wo die Prüfung streng ist, als Warnungen, wo sie nur berichtet. formfeed render gibt das Urteil des Validators aus, und ein strenges Rendering, dessen Datei nicht besteht, ist ein Befund mit Exit-Code 1. formfeed dev prüft die Seite, die es in der Vorschau zeigt.
• Engine: @formfeed/engine 0.3.13 exportiert die statische Vorlagenprüfung, die formfeed validate und die Validierung der API ausführen: staticAudit über die Quellen einer Vorlage, die Befunde mit den Regeln, die jeder verletzt (AUDIT_CODES, AUDIT_RULES), und resolveUa für die Einstellung. chart nimmt in seinen Optionen ein alt an, das ein Diagramm für PDF/UA-1 braucht. Die Prüfung der fertigen Datei gegen die Norm geschieht in der API, nicht im Paket.
• Dev Kit: @formfeed/devkit 0.3.13 exportiert diagnoseAccessibility, worauf die CLI aufbaut.
• SDKs: @formfeed/sdk und das Python-Paket formfeed 0.3.13 kennen den Bericht accessibility am Rendering: Accessibility, AccessibilityFailure und AccessibilityWarning in beiden, dazu PdfUaOptions für die Einstellung in TypeScript.
• MCP-Server: @formfeed/mcp 0.3.13 reicht den Bericht mit einem Rendering weiter und nennt einem Agenten, welche Regeln ein strenges Rendering verletzt hat und in welchen Elementen.
• @formfeed/testing, der n8n-Node und das Activepieces-Piece ziehen ohne eigene Änderungen auf 0.3.13 mit.

5. Oktober 2026: der Power-Automate-Connector ist zertifiziert

• Power Automate: Microsoft hat den Formfeed-Connector zertifiziert und am 5. Oktober freigegeben. Er funktioniert in Power Automate, Power Apps, Logic Apps und Copilot Studio, als Premium-Connector und zunächst als Preview wie jeder neu zertifizierte. Microsoft verteilt ihn jetzt Region für Region, was etwa zwei Wochen dauert; bis er in Ihrer Umgebung erscheint, stellt die HTTP-Aktion denselben Aufruf. Siehe Power Automate.

5. Oktober 2026: E-Rechnungen, die zugleich PDF/UA-1-Dateien sind

• API: settings.pdf.ua und eine E-Rechnung gehen jetzt zusammen. Das Rendering liefert eine Datei, die die ZUGFeRD- bzw. Factur-X-Rechnung, also ein PDF/A-3b, und zugleich ein PDF/UA-1-Dokument ist. Beides wird an der Datei geprüft, die ausgeliefert wird, und das Rendering trägt einvoice und accessibility. Bisher antwortete das Paar mit 400 invalid_request.
• API: Ein strenges Rendering, dessen E-Rechnung gültig ist und dessen Datei PDF/UA-1 nicht besteht, antwortet 422 pdfua_validation_failed mit beiden Berichten und liefert nichts aus. Mit { "check": "report" } wird die gültige E-Rechnung ohne die PDF/UA-Kennung ausgeliefert. einvoice_display_mismatch trägt ebenfalls accessibility, wenn das Rendering pdf.ua gesetzt hat.
• Geändert: post.watermark.text ist bei einer E-Rechnung erlaubt. Es antwortete mit 400 invalid_request, solange die Schrift des Wasserzeichens nicht eingebettet war.
• Geändert: Die Kennzeichnung einer Test-E-Rechnung ist Text in der eingebetteten Schrift, wie bei jedem anderen Test-Rendering. Einige Tage lang war sie ein Bild.
• Editor: Barrierefreies PDF (PDF/UA-1) und E-Rechnung sperren einander in der Seiteneinrichtung nicht mehr, und eine Vorlage, die beides festlegt, wird nicht mehr als Problem gemeldet.
• CLI: formfeed validate und POST /templates/{id}/validate melden für eine Vorlage, die beides festlegt, kein accessibility-einvoice mehr. In der CLI ab 0.3.13, der ersten Version mit der Prüfung.

5. Oktober 2026: barrierefreie PDFs (PDF/UA-1)

• API: settings.pdf.ua macht ein Rendering zu einem getaggten PDF im Format PDF/UA-1. Formfeed repariert, was die getaggte Ausgabe des Browsers falsch macht, prüft jede Datei gegen die maschinell prüfbaren Regeln der Norm und meldet das Urteil im neuen Feld accessibility des Renderings: ob die Datei bestanden hat, und zu jeder verletzten Regel, was an der Vorlage zu ändern ist und in welchen Elementen. true ist die strenge Prüfung, bei der ein Rendering, dessen Datei nicht besteht, mit dem neuen Problem pdfua_validation_failed fehlschlägt; { "check": "report" } liefert die Datei aus und berichtet. Es gehört zu jedem Plan und kostet keine zusätzliche Einheit. Eine bestandene Prüfung macht ein Dokument noch nicht barrierefrei: Barrierefreie PDFs sagt, was sie belegt und was bei der Vorlage bleibt.
• Editor: Die Seiteneinrichtung hat einen Abschnitt Dokument mit Titel, Autor, Thema und Stichwörtern des PDF, seinen Lesezeichen und Tags und Barrierefreies PDF (PDF/UA-1). Ist das eingeschaltet, prüfen die Vorschauen die Seite, und die Liste Probleme nennt jeden Befund an seiner Zeile; ein Echtes Rendering und das Render-Protokoll zeigen das Urteil des Validators.
• API: POST /templates/{id}/validate meldet für eine Version, die pdf.ua festlegt, einen fehlenden Titel und ein ohne alt geschriebenes Bild.
• CLI: formfeed validate meldet dasselbe für einen Vorlagenordner, formfeed render gibt das Urteil aus, und formfeed dev prüft die Seite, die es in der Vorschau zeigt. Die SDKs kennen das neue Feld, und der MCP-Server reicht es weiter. All das kommt mit den Paketen 0.3.13.
• Geändert: Ein getaggtes PDF (pdf.tagged, pdf.outline) erhält dieselben Reparaturen, ob es PDF/UA verlangt oder nicht: Kopf- und Fußzeilen und Schmuck werden als Artefakte markiert, und Links tragen eine Beschreibung.
• Geändert: Ein Text-Wasserzeichen und die Kennzeichnung von Test-Renderings werden in Noto Sans gesetzt, eingebettet in die Datei, statt wie bisher in Helvetica. Ein Text-Wasserzeichen nimmt jetzt auch griechische und kyrillische Buchstaben an.

5. Oktober 2026: Test-E-Rechnungen im Free-Plan

• API: Im Free-Plan erzeugen Test-Renderings jetzt E-Rechnungen: bis zu 20 pro Tag und Organisation, gezählt ab Mitternacht UTC, jede eine gültige ZUGFeRD-/Factur-X-Datei mit der Testmarkierung auf ihren Seiten. Bisher wurde ein Free-Workspace auch mit einem Test-Schlüssel abgelehnt. Ein Live-Rendering, das eine erzeugt, wird weiterhin mit 403 forbidden und "feature": "einvoice" abgelehnt.
• Fehler: Ein Test-Rendering über die 20 des Tages hinaus beantwortet die API mit demselben 403 forbidden und "feature": "einvoice", jetzt mit limit, used und resets_at, dem Beginn des nächsten UTC-Tages. In einem Batch zählt jedes Element, das eine E-Rechnung erzeugt, und nichts wird eingereiht, wenn nicht alle hineinpassen.
• Editor: Im Free-Plan funktioniert der Abschnitt E-Rechnung der Seiteneinrichtung wie in einem bezahlten Plan und sagt, was ein Test-Rendering ist. Das echte Rendering einer Rechnungsvorlage ist eine der 20 des Tages, ebenso Testanfrage senden im API-Tab.

5. Oktober 2026: Pakete 0.3.12

• CLI: formfeed 0.3.12 arbeitet offline mit E-Rechnungen. formfeed validate misst den _invoice-Block jedes Datensatzes an den Regeln, für jede Vorlage, deren settings.json eine E-Rechnung festlegt, und nennt Datei, Zeile, Feld und Regel. Das neue formfeed einvoice <slug> schreibt das XML, das ein Rendering einbetten würde, ohne API-Schlüssel. formfeed render sendet, was die Vorlage festlegt, und gibt den Bericht des Renderings aus.
• Engine: @formfeed/engine 0.3.12 exportiert den E-Rechnungs-Code, den die API vor einem Rendering ausführt: das Schema des _invoice-Blocks (invoiceSchema), die Prüfung, die zu jedem Befund die verletzte Regel nennt (checkInvoice), den Schreiber des XML (invoiceToCii, einvoiceXml) und die Prüfung, ob eine Seite zeigt, was das XML nennt (displayCheck). Die Umwandlung in PDF/A-3 und die Validierung der fertigen Datei geschehen in der API, nicht im Paket. Das Paket bekommt zod als Abhängigkeit.
• Dev Kit: @formfeed/devkit 0.3.12 exportiert, worauf die CLI aufbaut: declaredEinvoice, diagnoseEinvoice und localEinvoiceXml.
• SDKs: @formfeed/sdk und das Python-Paket formfeed 0.3.12 kennen post.einvoice an einem Rendering und einem Batch und den Bericht einvoice am Rendering: EinvoiceOptions, Einvoice und EinvoiceMessage in TypeScript, Einvoice, EinvoiceValidation, EinvoiceDisplay und EinvoiceMessage in Python.
• @formfeed/testing, der MCP-Server, der n8n-Node und das Activepieces-Piece ziehen ohne eigene Änderungen auf 0.3.12 mit.

4. Oktober 2026: E-Rechnungen

• API: Ein PDF-Rendering kann eine E-Rechnung im Format ZUGFeRD / Factur-X sein: ein PDF/A-3b, das die Rechnung als factur-x.xml trägt, in den Profilen EN 16931 und Basic, aus einer HTML- oder Word-Vorlage oder aus HTML, das mit der Anfrage kommt. Angefordert wird sie mit post.einvoice an einem Rendering oder einem Batch, oder einmal festgelegt in settings.einvoice der Vorlage. Die Rechnung ist der _invoice-Block in data, und die Vorlage druckt aus demselben Block.
• Validierung: Der Block wird an den Regeln gemessen, bevor etwas gerendert wird, und die fertige Datei wird validiert, bevor sie ausgeliefert wird. Ein gelungenes Rendering trägt den Bericht im neuen Feld einvoice des Renderings, das auch die Webhook-Events enthalten. Mit xml: "both" liegt das XML zusätzlich neben dem PDF und ist als einvoice.xml_url verlinkt. Eine Datei, die nicht besteht, wird nicht ausgeliefert, und an ihrer Stelle auch kein gewöhnliches PDF.
• Fehler: fünf neue Codes: einvoice_data_invalid, einvoice_profile_unsupported, einvoice_display_mismatch, pdfa_conversion_failed und conformance_unavailable.
• Pläne: E-Rechnungen setzen den Starter-Plan oder höher voraus und kosten 1 Einheit zusätzlich zum Rendering. Test-Schlüssel, Vorschauen und fehlgeschlagene Renderings kosten nichts. Im Free-Plan antwortet die API mit 403 forbidden und "feature": "einvoice". Siehe Pläne und Einheiten.
• Editor: Die Seiteneinrichtung einer PDF-Vorlage hat einen Abschnitt E-Rechnung mit dem Schalter, dem Format und dem Profil und einer Karte, die sagt, was dem _invoice-Block des Datensatzes fehlt, jeder Befund mit seiner Regel. Die Vorschau zählt die Werte des XML, die sie zeigt, und ein echtes Rendering und das Render-Protokoll zeigen den Bericht des Validators, der sich als JSON herunterladen lässt.

2. Oktober 2026: Bilder zur Auswahl auf der Arbeitsfläche

• Editor: Auf der Arbeitsfläche nannte eine Bild-Ebene, die ihr Bild aus der Dateibibliothek nimmt, die Datei in einem Textfeld; man musste also wissen, wie sie heißt. Datei im Inspektor öffnet jetzt die Bilder der Dateibibliothek des Workspace, die neuesten zuerst, mit einer Suche nach dem Namen. Das verwendete Bild ist markiert, und Bild hochladen in derselben Liste fügt eine Datei hinzu und zeigt sie sofort auf der Ebene. Ein langer Dateiname wird im Feld gekürzt und erscheint vollständig, wenn Sie mit der Maus darauf zeigen.
• Behoben: Eine Bild-Ebene nahm ein PDF an, über ihren Upload oder wenn eines auf die Arbeitsfläche gezogen wurde, weil die Bibliothek auch PDFs enthält. Es wurde hochgeladen und stand dann als defektes Bild auf der Arbeitsfläche. Eine Bild-Ebene nimmt jetzt nur Bilder an und sagt, welche Datei keines ist.
• Behoben: Die Suche der Seite Dateien las _ und % in der Eingabe als Platzhalter; hero_2x fand deshalb auch hero-2x.png. Beide Zeichen stehen jetzt für sich selbst.

2. Oktober 2026: ältere Versionen, und Seiten, die auf ihren Workspace warten

• Editor: Das Panel Versionen zeigte die neuesten fünfzig Versionen einer Vorlage und keinen Weg zu den früheren; eine häufiger gespeicherte Vorlage ließ sich in der App nicht mit ihren frühen Versionen vergleichen und nicht auf sie zurücksetzen. Ältere Versionen anzeigen unter der Liste holt sie, jeweils fünfzig, und die Zeile darüber sagt 50+ gespeichert, solange es weitere gibt.
• Behoben: Bei einer langsamen Verbindung sagten Seiten etwas über einen Workspace, den sie noch nicht kannten: Das Render-Protokoll zeigte „Noch keine Renderings“, die Seiten für API-Schlüssel und Webhooks verwiesen an einen Inhaber, und die Abrechnung zeigte den Free-Plan als aktuellen Plan, bis die Organisation geladen war. Jetzt erscheint keine Seite eines Workspace, bevor der Workspace bekannt ist, und das Render-Protokoll zeigt nicht mehr „Keine Renderings passen zu den Filtern“, während seine erste Antwort unterwegs ist.
• Behoben: Eine Adresse, deren Workspace es nicht gibt (ein gelöschter Workspace, ein vertippter Link), zeigte eine leere App. Sie führt zum ersten Workspace der Organisation oder zur Liste der Organisationen.
• Behoben: Mit eingeschaltetem Text bearbeiten ging ein Klick auf einen Text in dem Moment verloren, in dem die Vorschau ihr nächstes Dokument übernahm, oder der Text öffnete sich nur, um sich wieder zu schließen. Der Text öffnet sich jetzt im neuen Dokument, ohne zweiten Klick.

2. Oktober 2026: Korrekturen im Editor und auf der Vorlagenseite

• Behoben: Mit eingeschaltetem Text bearbeiten verlor ein Text, der gleich nach der Änderung davor angeklickt wurde (Enter, dann der nächste Text), seinen Cursor, sobald die Vorschau die erste Änderung zeigte, und das dort Getippte war weg. Die Vorschau wartet mit diesem Rendering jetzt, bis der Text fertig ist.
• Behoben: Auf der Arbeitsfläche verlor ein Klick in das Textfeld des Inspektors den Fokus an die Arbeitsfläche, wenn er in dem Moment kam, in dem sich ein Text zum Tippen öffnete, und das für das Feld Getippte landete im Text auf der Arbeitsfläche. Der Fokus bleibt jetzt dort, wo Sie ihn hingesetzt haben.
• Behoben: Echtes Rendering schlug mit „all render slots are busy“ fehl, solange der Renderer ausgelastet war. Es wartet jetzt bis zu 20 Sekunden auf einen freien Platz.
• Behoben: Bei einer langsamen Verbindung zeigte die Vorlagenseite „Noch keine Vorlagen“, bis die Liste eines Workspace angekommen war, und Vorlage anlegen im Dialog Neue Vorlage tat nichts, wenn es gedrückt wurde, bevor der Workspace geladen war. Die Seite zeigt die Liste jetzt als ladend, und die Schaltfläche ist verfügbar, sobald der Workspace da ist.

2. Oktober 2026: das API-Panel einer Vorlage

• Editor: Jede Vorlage hat ein Panel API: die Anfrage, die sie rendert, in curl, TypeScript, Python, PHP, Go, C#, Java und Ruby, mit dem Slug der Vorlage und ihrem Datensatz als data.json. Die erste Zeile sagt, welche Version ein Aufruf rendert, und ein Schalter nimmt den neuesten Entwurf in die Anfrage auf, wenn einer vor der veröffentlichten Version liegt. Siehe die Editor-Tour.
• Editor: Inhaber und Admins legen im Panel einen Test-Schlüssel an, einmal angezeigt als die export-Zeile, die eine Shell braucht. Testanfrage senden schickt die Anfrage als Test-Rendering durch die API und zeigt die Antwort: die Datei, das Rendering im Render-Protokoll und das JSON, oder das Problem mit der Seite zu seinem Code. In jedem Plan kostenlos.
• App: ?panel=api an der Adresse einer Vorlage öffnet das Panel, ebenso API-Anfrage im Menü einer Zeile der Vorlagenliste und der letzte Schritt der Checkliste Erste Schritte. Nach Diese Vorlage verwenden führt der Hinweis im Editor dorthin statt auf die Seite des Beispiels, denn das Panel nennt den Slug der Kopie.
• API: Das Problem, mit dem POST /v1/renders antwortet, wenn ein Rendering fehlschlägt, trägt jetzt die render_id des Renderings, wie es das Problem seines Ergebnisses bereits tat. Siehe Fehler.

2. Oktober 2026: Rendern mit der ID der Vorlage

• Behoben: POST /v1/renders und POST /v1/renders/batch antworteten mit 404 template_not_found, wenn template die tpl_…-ID war, die die Templates-API zurückgibt. Sie kannten nur den Slug und die reine UUID. Slug und tpl_…-ID funktionieren jetzt beide, wie es die Referenz immer gesagt hat.
• Behoben: Ein Rendering nannte seine Vorlage in template.id mit der UUID der Datenbank, in API-Antworten und in Webhook-Events, während die Templates-API tpl_… ausgibt und diese Seiten immer tpl_… gezeigt haben. Renderings und Events tragen jetzt die tpl_…-ID, eine Vorlage hat also eine ID. Eine gespeicherte UUID funktioniert weiterhin überall, wo eine Vorlage genannt wird: Eine Render-Anfrage, der Filter template von GET /v1/renders und die Templates-API nehmen den Slug, die tpl_…-ID oder die UUID.

2. Oktober 2026: Pakete 0.3.11

• n8n-Node: n8n-nodes-formfeed 0.3.11 lässt sich mit dem Eingang Tools des AI-Agent-Nodes von n8n verbinden; der Agent wählt dann die Operation und füllt ihre Felder aus. Ein selbst gehostetes n8n bietet Community-Nodes nur dann als Tools an, wenn die Instanz N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true setzt. Siehe n8n.
• CLI: formfeed 0.3.11 behält ein Design des visuellen Editors bei seiner Vorlage: templates pull schreibt es in design.json, push sendet es zurück, und validate warnt mit design-stale, wenn template.html oder style.css danach bearbeitet wurden, und mit design-invalid, wenn die Datei kein Design ist, das die App öffnen kann. Siehe die Projektstruktur.
• Engine: @formfeed/engine 0.3.11 rendert lokal, was die API seit Ende September rendert. Text mit data-ff-fit="shrink" wird an seine Box angepasst; barcode setzt die Ziffern eines EAN-13, EAN-8 oder UPC-A neben die langen Randstriche statt durch sie hindurch; und qrcode, qr und barcode beantworten einen leeren Wert mit einer Meldung, die den Helper nennt („nothing to encode, the value is empty or missing from the data“), statt mit der der Code-Bibliothek. Das Paket exportiert außerdem das Design-Format (parseDesign, emitDesign).
• Snapshots: Weil formfeed test und @formfeed/testing das Dokument vergleichen, das die Engine zusammensetzt, ändert sich ein Snapshot mit einem dieser drei Barcodes oder einem angepassten Text einmal mit 0.3.11. Sehen Sie sich den Unterschied an und bestätigen Sie ihn mit formfeed test -u.
• Die SDKs, der MCP-Server und das Activepieces-Piece ziehen ohne eigene Änderungen auf 0.3.11 mit.

2. Oktober 2026: die Arbeitsfläche nach ihren ersten Testern

• Editor: Ein Text, der auf der Arbeitsfläche hinzugefügt wird, öffnet sich sofort zum Tippen, sein Platzhalter ist markiert; ein gewählter Text nimmt auf, was Sie tippen, und ein Klick auf ihn setzt den Cursor. Ein runder Griff unter der Auswahl verschiebt die Ebene, auch während in ihren Text getippt wird.
• Editor: Fett, kursiv, unterstrichen und das neue Durchgestrichen sind Umschalter mit den üblichen Tasten (Strg+B, Strg+I, Strg+U), die Schriftstärken stehen mit Namen in der Liste, und ein neuer Text beginnt normal. Jede Ebene hat im Inspektor einen Schatten: hinter den Buchstaben eines Texts, hinter der Box jeder anderen Ebene.
• Editor: Ein Bild in der Zwischenablage lässt sich mit Strg+V auf die Arbeitsfläche einfügen (es wird zuerst in die Dateibibliothek hochgeladen), und Eigene Schriften hochladen unter der Liste der Schriften fügt der Organisation Schriftdateien hinzu, ohne den Editor zu verlassen.
• Behoben: Die Bild-Schaltfläche der Leiste schloss die Arbeitsfläche mit „Das Design lässt sich nicht öffnen“. Eine neue Bild-Ebene wartet jetzt auf ihr Bild: Die Arbeitsfläche und die Liste Probleme sagen das, und bis eines gewählt ist, wird sie als leere Box gerendert.
• API: In settings.design darf der style einer Text-Ebene strike: true tragen, und die source einer Bild-Ebene darf ein leeres asset, url oder path enthalten, solange noch kein Bild gewählt ist.

2. Oktober 2026: mit einem Beispiel beginnen, und das Limit der Vorlagen

• App: Die Vorlagen von formfeed.dev/de/examples stehen in der App bereit. Vorlagen → Beispiele listet sie mit einer Suche und Filtern für Gruppe, Art und Engine, und Diese Vorlage verwenden legt eine Kopie im Workspace an: Einstellungen, Übersetzungen und Beispieldaten des Beispiels, veröffentlicht als Version 1, sodass ein Rendering mit dem Slug der Kopie sofort funktioniert. Jede Beispielseite der Website hat denselben Button; er führt über die Anmeldung zu diesem Beispiel. Siehe den Schnellstart.
• API: Die Zahl der Vorlagen, die ein Plan umfasst, wird jetzt durchgesetzt: fünf im Free-Plan, keine Begrenzung ab Starter. POST /v1/templates darüber hinaus antwortet mit 403 forbidden, feature: "templates" und dem limit. Archivierte Vorlagen zählen nicht, und eine archivierte lässt sich nicht wiederherstellen, solange der Plan voll ist. Vorlagen, die eine Organisation bereits hat, bleiben unverändert, und Renderings sind nicht betroffen.

30. September 2026: Text in der Vorschau bearbeiten und eine Arbeitsfläche für Bildvorlagen

• Editor: Ist Text bearbeiten eingeschaltet, bearbeitet ein Klick auf eine Überschrift, einen Absatz oder eine übersetzte Beschriftung in der Fluss- oder Seitenvorschau den Text an Ort und Stelle. Werte aus den Daten bleiben Chips, die Änderung geht als eine Bearbeitung, die Strg+Z rückgängig macht, in die Vorlage (oder in das Wörterbuch der Sprache, die die Vorschau zeigt), und Text, den die Vorschau nicht sicher bearbeiten kann, etwa Kontrollfluss, wird stattdessen im Code gezeigt. Siehe die Editor-Tour.
• Editor: Bildvorlagen lassen sich auf einer Arbeitsfläche gestalten, in der Beta: Text, Bilder, Formen, QR-Codes und Barcodes als Ebenen, Text aus Feldern der Daten, Markenfarben und -schriften, Text, der sich seiner Box anpasst, Lineale und Hilfslinien zum Einrasten und eine Prüfung jedes Datensatzes auf Text, der nicht passt. Der Editor schreibt HTML und CSS der Vorlage aus dem Design; Renderings, die API und die SDKs sehen also eine gewöhnliche Vorlage. Siehe den visuellen Editor.
• Vorlagen: data-ff-fit="shrink" gibt dem Text einer Box fester Größe die größte Schriftgröße, mit der er passt, in jeder Vorlage: siehe Text an seine Box anpassen.
• API: settings.design einer Version enthält die Ebenen der Arbeitsfläche (Einstellungen); es darf höchstens 256 kB groß sein, und Renderings beachten es nicht.
• CLI: Ab dem nächsten Release schreibt formfeed templates pull ein Design in design.json, push sendet es zurück, und formfeed validate warnt, wenn template.html oder style.css nicht mehr dazu passen.

29. September 2026: Deduplizierung, die Locales und Übersetzungen kennt

• Behoben: Zwei Live-Renderings desselben Templates mit denselben Daten und verschiedenen Locales ("locale": "de", danach "locale": "en") innerhalb des Zeitfensters der Deduplizierung beantworteten das zweite mit dem Dokument des ersten, in dessen Sprache. Die Locale gehört jetzt zu dem, was zwei Renderings identisch macht; Renderings ohne locale werden wie bisher dedupliziert.
• Behoben: Eine Template-Version, die nur ihre Übersetzungen änderte, hatte dieselbe Prüfsumme wie die Version davor. Live-Renderings mit denselben Daten konnten deshalb bis zu 24 Stunden nach dem Veröffentlichen noch den alten Wortlaut aus dem Cache der Deduplizierung bekommen, und template_checksum unterschied die beiden Versionen nicht. Ab jetzt gespeicherte Versionen nehmen ihre Übersetzungen in die Prüfsumme auf; die Prüfsummen bestehender Versionen ändern sich nicht.

28. September 2026: das Ergebnis eines Renderings

• API: Das neue GET /v1/renders/{id}/result antwortet mit 202 und Retry-After, solange ein Rendering wartet oder läuft. Ist das Rendering fertig, antwortet es wie die synchrone Anfrage: mit dem Rendering, mit der Datei bei ?output=binary oder mit dem Fehler des Renderings als Problem samt render_id. Das Location jedes 202 von POST /v1/renders nennt jetzt diese URL, absolut und mit output=binary, wenn die Anfrage die Datei verlangt hat, und das 202 trägt Retry-After: 5. GET /v1/renders/{id} bleibt unverändert; Code, der es abfragt, etwa waitFor der SDKs, muss nicht angepasst werden. Siehe den automatischen Wechsel.
• Power Automate: Weil Power Automate diesem Location von selbst folgt, wartet eine Aktion, deren Rendering die einminütige Frist einer synchronen Anfrage überschreitet, jetzt auf das Dokument, statt ein unfertiges Rendering zurückzugeben.

25. September 2026: Pakete 0.3.10

• MCP-Server: Die sechs Tools von @formfeed/mcp 0.3.10 beschreiben, wann welches Tool statt eines anderen passt, was ein Aufruf kostet und zurückgibt und was schiefgehen kann, und jeder Parameter sagt, wofür er da ist. render sagt, dass es die veröffentlichte Version einer Vorlage rendert, eine nie veröffentlichte Vorlage also mit template_not_found scheitert, und dass Test-Schlüssel das Wasserzeichen nur im Free-Plan tragen. Der gehostete Server unter mcp.formfeed.dev hat die neuen Beschreibungen bereits. Die SDKs, die CLI, @formfeed/engine, @formfeed/testing, der n8n-Node und das Activepieces-Piece ziehen unverändert auf 0.3.10 mit.

23. September 2026: Pakete 0.3.9

• SDKs: @formfeed/sdk und das Python-SDK formfeed 0.3.9 bringen die storage-Ergänzungen, die unter eigener Speicher stehen.
• CLI: formfeed init --from-workspace holt auch die geteilten Partials der Organisation, die seine Vorlagen einbinden, sodass das erste formfeed validate nicht mehr an einem fehlenden Partial scheitert; für ältere Projekte nennt die Fehlermeldung jetzt formfeed partials pull. formfeed templates diff vergleicht Einstellungen und Beispieldaten unabhängig von der Reihenfolge der Schlüssel, ein frischer Pull zeigt also keine Änderungen. Die Ausgabe nennt Dateien relativ zu dem Ordner, in dem der Befehl lief; --json behält absolute Pfade.
• MCP-Server: @formfeed/mcp 0.3.9 gibt bei jedem Tool readOnlyHint, destructiveHint und openWorldHint an, sodass Clients die vier Tools, die nur lesen, von render und convert_to_pdf unterscheiden können, die ein Rendering anlegen. Der gehostete Server unter mcp.formfeed.dev hat sie bereits.
• Activepieces: Der Verbindungstext von @formfeed/activepieces-piece 0.3.9 sagt, dass die Standard-Scopes eines Schlüssels bleiben sollen, weil die Verbindungsprüfung account:read braucht, und dass file:write und webhook:manage dazukommen. @formfeed/engine, @formfeed/testing und der n8n-Node ziehen unverändert auf 0.3.9 mit.

23. September 2026: eigener Speicher

• Eigener Speicher (ab dem Pro-Plan): Inhaber und Admins verbinden auf der neuen Karte Eigener Speicher unter Einstellungen einen Bucket bei Amazon S3, Cloudflare R2 oder einem S3-kompatiblen Dienst (Hetzner, IONOS, Scaleway, Wasabi, Backblaze B2, MinIO, Google Cloud Storage). Formfeed schreibt ein Testobjekt, bevor es die Verbindung speichert, und kopiert danach jedes Dokument des Workspace im Hintergrund in den Bucket: Renderings, Einträge und Zips von Batches, Ergebnisse der PDF-Tools und Office-Renderings. Es schreibt nur (PutObject), liest, listet und löscht nie und behält die eigene Kopie für die Aufbewahrungsfrist des Workspace, download_url funktioniert also wie bisher. Die Kopie geht dorthin, wo Ihr Bucket liegt; siehe Datenresidenz. Siehe Eigener Speicher.
• API: Renderings, Einträge von Batches und die PDF-Tools, /pdf/convert eingeschlossen, nehmen storage: { "key": "invoices/2026/RE-1001.pdf" } benennt das Objekt unterhalb des Präfixes der Verbindung, false lässt das Dokument aus. Ein Rendering mit eigenem Schlüssel wird nie dedupliziert. Renderings und Jobs haben das neue Feld storage (status, bucket, key, url, reason, error); ein synchrones Rendering meldet pending. Die Routen unter /v1/workspaces/{id}/storage dienen der App und nehmen die Sitzung eines Inhabers oder Admins; noch kann kein API-Schlüssel eine Verbindung verwalten.
• Webhooks: die Ereignisse storage.delivered und storage.failed, als Opt-in: Kein Endpunkt erhält sie, bevor seine Ereignisliste sie nennt. Dauerhafte Fehler wie AccessDenied schlagen sofort fehl, andere Fehler werden nach dem Zeitplan der Webhooks wiederholt, und fünf dauerhafte Fehlschläge in Folge pausieren die Verbindung und benachrichtigen Inhaber und Admins per E-Mail. Die erneute Zustellung sendet fehlgeschlagene Kopien erneut, ohne neu zu rendern.
• Neue Fehlercodes: storage_not_configured (409) und storage_test_failed (422).
• SDKs: storage bei Renderings und PDF-Tools, Render.storage und die Typen StorageOption, StorageDelivery, StorageDeliveryEvent und WebhookEventType in @formfeed/sdk; das Schlüsselwortargument storage=, render.storage und die Modelle StorageDelivery, StorageDeliveryEvent und StorageError im Python-SDK. Mit ihrem nächsten Release.

23. September 2026: Zap-Vorlagen

• Zapier: Fertige Zaps für Google Forms, Typeform, Google Sheets, Google Drive, Stripe und Slack stehen in Zapiers Verzeichnis. Wer mit einer davon beginnt, hat den Trigger und den Formfeed-Schritt schon beisammen und wählt nur noch die beiden Konten und die eigene Vorlage; unter Integrationen in der App stehen sie ebenfalls. Siehe Zapier.

22. September 2026: Pakete 0.3.8

• Activepieces: Das Formfeed-Piece erscheint mit den übrigen Paketen, als @formfeed/activepieces-piece 0.3.8 mit Provenance; installiert wird es über diesen Namen unter Platform Admin → Setup → Pieces. Siehe Activepieces.
• MCP-Server: @formfeed/mcp 0.3.8 steht in der offiziellen MCP-Registry als io.github.formfeed-dev/formfeed. Die übrigen Pakete ziehen unverändert auf 0.3.8 mit.

22. September 2026: Formfeed in Zapiers App-Verzeichnis

• Zapier: Die Formfeed-App ist in Zapiers App-Verzeichnis gelistet; ein Einladungslink ist nicht mehr nötig. Ihre Version 0.1.0 bringt Convert Document to PDF, DOCX und PPTX als Ausgabe von Create Document und das Feld Version für Release Channels zu Zapier. Bestehende Zaps bleiben auf 0.0.0, bis sie umgezogen werden. Siehe Zapier.

22. September 2026: ein Vorlagenschema für Power Automate

• API: GET /templates/{id}/schema nimmt format=swagger und antwortet { "schema": … } im Dialekt von OpenAPI 2.0, den Power Automate für dynamische Felder liest: ein Typ je Eigenschaft, kein nullable und kein oneOf, eine Beschriftung in x-ms-summary. Wie bei format=make beschreibt es eine Vorlage ohne gespeichertes Schema über ihre Beispieldaten und eine ohne beides mit einem Objekt ohne Eigenschaften statt mit einem 404.
• API: POST /webhooks antwortet 201 mit einem Location-Header, der absoluten URL des neuen Endpunkts.
• API: Die Formularfelder landscape und single_page_sheets eines Uploads an POST /pdf/convert nehmen true und false in beliebiger Schreibweise an, sodass True aus einem .NET-Client funktioniert.

21. September 2026: Diagramme in der Größe der Seite, auf die sie gedruckt werden

• Rendering: Ein PDF wird in einem Fenster angelegt, das so breit und so hoch ist wie sein Papier (A4: 794 × 1123 CSS-Pixel; Querformat und eigene Größen entsprechend), statt in festen 1240 × 1754. Der Druck hat die Seite schon immer in Papierbreite angelegt, aber Skripte laufen vorher und haben das breitere Fenster vermessen: Eine Diagrammbibliothek, die sich nach ihrem Container bemisst, zeichnete Diagramme zu groß für die Seite, und ein importierter apitemplate.io-Bericht wurde eine Seite länger als dort. Vorlagen ohne Skripte, die das Fenster vermessen, drucken wie bisher; eine Vorlage, deren Skript window.innerWidth liest, liest jetzt die Breite des Papiers.

21. September 2026: ein Editor, der sagt, wann das PDF schrumpft

• Editor: Ist ein Element breiter als die Seite, sagt „Probleme" es — um wie viele Millimeter, und auf welche Größe Chromium jede Seite des PDFs verkleinert, damit es passt — und springt zum Tag des Elements. Chromium verkleinert für ein einziges solches Element das ganze PDF, was keine Vorschau bei 100 % zeigen kann. Die fortlaufende und die paginierte Vorschau messen nach jedem Umbruch.
• Editor auf Deutsch: Die Probleme einer Vorlage (ein Name, den die Beispieldaten nicht haben, ein unbekannter Helper, ein Block, der nie geschlossen wird) erscheinen in der deutschen App auf Deutsch; Syntaxfehler der Template-Parser bleiben englisch.

21. September 2026: Snapshot-Tests sehen Kopf- und Fußzeile

• CLI: Der Snapshot, den formfeed test für eine HTML-Vorlage vergleicht, enthält jetzt neben dem Dokument auch die gerenderte Kopf- und Fußzeile, unter den Zeilen <!-- formfeed:header --> und <!-- formfeed:footer -->; bisher ging eine Änderung an header.html oder footer.html unbemerkt durch, weil Chromium sie außerhalb des Dokuments druckt. formfeed renders pull --snapshot schreibt dieselbe Form. Haben Ihre Vorlagen eine Kopf- oder Fußzeile, scheitert das erste formfeed test nach dem Update einmal: formfeed test -u ausführen und die Snapshots committen. In formfeed 0.3.7; die übrigen Pakete ziehen mit auf 0.3.7, @formfeed/engine mit den args seiner Diagnosen und der Breitenmessung der Vorschauen.

21. September 2026: kein NaN auf einem Dokument, und eine MCP-Prüfung, die das Schema kennt

• Template-Engine: money, number und numToWords brechen das Rendern mit einem template_runtime_error ab, wenn eine Rechnung ihnen NaN oder Unendlich übergibt — Arithmetik mit einem Wert, der Text ist ("19 %") oder fehlt —, statt NaN auf das Dokument zu drucken. Eine Vorlage, die bisher NaN gedruckt hat, scheitert jetzt an dieser Stelle. Text, der keine Zahl ist ("auf Anfrage"), und fehlende Werte erscheinen wie bisher. POST /templates/{id}/validate meldet denselben Fehler, ohne zu rendern.
• MCP-Server: validate_template mit einem Template-Slug fragt POST /templates/{id}/validate für die Version, die ein Render verwenden würde; die Daten werden also gegen das gespeicherte Schema der Vorlage geprüft und einmal mit der Vorlage ausgeführt. Ad-hoc-html wird weiterhin offline geprüft. In @formfeed/mcp 0.3.6; die übrigen Pakete ziehen mit auf 0.3.6.

18. September 2026: Zwei-Faktor-Authentifizierung

• App: Schützen Sie Ihr Konto mit einem Code aus einer Authenticator-App (TOTP): Zwei-Faktor-Authentifizierung im Menü unter Ihrem Namen. Freiwillig, pro Person und in jedem Plan; es lassen sich mehrere Authenticatoren hinzufügen, damit ein zweiter für ein verlorenes Handy einspringen kann. Jeder Weg der Anmeldung fragt nach dem Code, auch das Zurücksetzen des Passworts. Siehe Zwei-Faktor-Authentifizierung.
• API: unverändert für API-Schlüssel, die nie nach einem Code fragen. Ein Sitzungs-Token eines Kontos mit Zwei-Faktor-Authentifizierung wird erst akzeptiert, wenn seine Sitzung den Code bestanden hat, und das OAuth-Token eines Agenten am gehosteten MCP-Endpunkt erst, nachdem das Konto diesen Agenten aus einer solchen Sitzung erlaubt hat; sonst antwortet die API mit 403 forbidden und sagt, welcher der beiden Fälle vorliegt. Das Einschalten der Zwei-Faktor-Authentifizierung meldet verbundene Agenten ab, sie müssen also neu verbunden werden.

18. September 2026: Pushes mit Konflikt, und eine CLI, die ihren Fortschritt zeigt

• Behoben: Das Anlegen einer Template-Version mit einem base_checksum, der nicht mehr zur neuesten Version gehört (formfeed templates push, nachdem das Template in der App oder von einem anderen Rechner geändert wurde), bekam nie eine Antwort; die Anfrage hing, bis der Client aufgab. Sie antwortet jetzt sofort mit 409 conflict, wie dokumentiert. Erst pullen und zusammenführen, oder mit --force pushen.
• CLI 0.3.5: templates push und pull, partials push, files push und pull, ci preview und render geben jedes Ergebnis aus, sobald es fertig ist, statt alles am Ende, mit einer Schlusszeile, die zusammenzählt. Im Terminal nennt eine laufende Zeile das Template, das gerade dran ist, was damit geschieht und wie lange schon, und sagt es, wenn die API ungewöhnlich lange braucht. Farbe gibt es nur im Terminal (NO_COLOR und FORCE_COLOR werden beachtet); --json, Pipes und CI-Logs bleiben unverändert. Die übrigen Pakete ziehen mit auf 0.3.5.

17. September 2026: gehosteter MCP-Endpunkt mit Anmeldung

• MCP: mcp.formfeed.dev ist live. https://mcp.formfeed.dev/mcp/<workspace id> meldet sich mit Ihrem Formfeed-Konto an (OAuth 2.1; der Client öffnet den Browser, und Sie erlauben es auf der neuen Zustimmungsseite), https://mcp.formfeed.dev/mcp nimmt einen API-Schlüssel. Ein angemeldeter Agent liest Vorlagen und rendert, sonst nichts, unabhängig von Ihrer Rolle. Siehe MCP-Server.
• Pakete 0.3.4: @formfeed/mcp --http nimmt --auth-server und --public-origin für dieselbe Anmeldung gegen Ihr eigenes Supabase Auth, und @formfeed/sdk nimmt headers, die mit jeder Anfrage gesendet werden; die übrigen Pakete ziehen mit auf 0.3.4.

17. September 2026: Release Channels überall, wo eine Version genannt wird

• API: POST /templates/{id}/validate nimmt einen Channel-Namen als version, und GET /templates/{id}/schema liest das Schema der Version, die ?version= nennt (published, latest, eine Nummer oder ein Channel). Mit ?format=make kommt zusätzlich ein Auswahlfeld version zurück, wenn die Vorlage neben published weitere Channels hat.
• SDKs: templates.schema(id, { version }) in @formfeed/sdk und templates.schema(id, version=...) in Python; validate nimmt einen Channel-Namen. Mit ihrem nächsten Release.
• n8n, Zapier, Make: ein Feld Version, das die Release Channels der Vorlage listet. n8n nimmt auch eine Versionsnummer als Expression; Zapier und Make zeigen das Feld nur bei Vorlagen mit benannten Channels. Zapier und Make erhalten es mit der nächsten App-Version.
• App: Die Vorlagenliste hat eine Spalte Channels mit den benannten Channels jeder Vorlage.

17. September 2026: parallele synchrone Renderings

• Behoben: Synchrone Renderings, die parallel über die freien Render-Slots hinaus gesendet wurden, antworteten mit 503 region_unavailable und blieben im Rendering-Protokoll dauerhaft In Warteschlange oder Wird gerendert. Sie warten jetzt wie dokumentiert auf einen Slot; wer innerhalb von 30 Sekunden keinen findet, wird zu einem asynchronen Rendering (202, X-Render-Async-Fallback: true), das im Hintergrund fertig wird. Siehe Rendering.
• apitemplate.io-Kompatibilität: Die Endpunkte warten auf ein solches Rendering und antworten mit dem Dokument (bisher antwortete ein Rendering im Hintergrund mit success ohne download_url), geben Retry-After weiter und antworten mit 504 render_timeout und der transaction_ref, wenn ein Rendering länger als zwei Minuten läuft. Siehe apitemplate.io-Kompatibilität.

17. September 2026: Office-Vorlagen im Validierungs-Endpunkt

• API: POST /templates/{id}/validate prüft jetzt auch Word- und PowerPoint-Vorlagen: die Tags des gespeicherten Dokuments, Fehler, die erst beim Füllen mit den Daten auftreten, und die Daten gegen das gespeicherte Schema. Ihre Meldungen tragen die neuen Felder part und paragraph.
• SDKs: Diagnostic hat in @formfeed/sdk und im Python-SDK mit dem nächsten Release die Felder part und paragraph.

17. September 2026: PDF-Umwandlung in Agenten und No-Code-Apps

• Pakete 0.3.2: @formfeed/mcp und n8n-nodes-formfeed mit den Änderungen unten; die übrigen Pakete ziehen auf 0.3.2 mit.
• MCP: Das neue Werkzeug convert_to_pdf wandelt ein Word-, Excel-, PowerPoint-, OpenDocument- oder RTF-Dokument oder das Rendering einer Word- oder PowerPoint-Vorlage in ein PDF um. Der lokale Server liest eine Datei auch über ihren Pfad. Siehe MCP-Server.
• n8n: Die Ressource PDF wandelt ein Dokument aus einem Binärfeld oder ein Rendering um; Output bietet DOCX und PPTX an, und der Name einer heruntergeladenen Datei trägt die Endung dessen, was gerendert wurde. Siehe n8n.
• Zapier: Die Aktion Convert Document to PDF sowie DOCX und PPTX als Ausgabe von Create Document. Sie kommen mit der nächsten Version der App zu Zapier. Siehe Zapier.
• Make: Das Modul Convert a document to PDF sowie DOCX und PPTX als Ausgabe von Create a document, mit dem nächsten Deploy der App. Siehe Make.
• Navigation: Verbrauch steht jetzt im Organisationsbereich der Seitenleiste, neben Abrechnung: Einheiten zählen für die ganze Organisation, und die Seite schlüsselt sie nach Workspace auf.
• Pakete 0.3.3: @formfeed/engine mit der round-Korrektur sowie CLI, Dev-Kit und Test-Helfer, die damit lokal rendern.
• Behoben: round(x, 0, 'floor') und round(x, 0, 'ceil') rundeten zum nächsten Wert; sie runden jetzt wie in Jinja2 ab und auf, auch als method='floor', in allen drei Template-Sprachen. Die Helfer-Referenz sagt jetzt, dass number ohne Nachkommastellen die eigenen Nachkommastellen der Zahl behält, höchstens drei; number(0) ergibt ganze Zahlen.

17. September 2026: Pakete 0.3.1

• Pakete 0.3.1: @formfeed/sdk, formfeed (Python), formfeed (CLI), @formfeed/engine, @formfeed/devkit, @formfeed/testing, @formfeed/mcp und n8n-nodes-formfeed mit den folgenden Korrekturen.
• Word-Vorlagen: Ein Tag in einem Feldcode (HYPERLINK, REF, …) bleibt, wie es ist, und das Panel Tags, formfeed validate und der MCP-Server warnen jetzt davor (office-tag-in-field).
• CLI: ignore in formfeed.json lässt passende Vorlagenordner jetzt bei formfeed templates push ohne Slug aus (die Einstellung wurde gelesen, wirkte aber nicht); formfeed renders pull funktioniert für Renderings von Word- und PowerPoint-Vorlagen; das echte Rendering von formfeed dev nutzt bei Bildvorlagen deren eigenes Format statt immer PNG. Siehe Konfiguration.
• MCP: list_templates filtert nach docx und pptx, und validate_template prüft das Dokument einer Word- oder PowerPoint-Vorlage und nennt Teil und Absatz. Siehe MCP-Server.
• Behoben: formfeed render, formfeed ci preview und das echte Rendering von formfeed dev druckten Kopf- und Fußzeilen-Vorlagen ungefüllt ({{ company.name }}); sie werden jetzt mit denselben Daten wie der Inhalt gefüllt gesendet.
• Jinja2: sum(attribute='total') und sum(attribute=…, start=…) addieren das Attribut (sie ergaben 0), und {{ values }} gibt eine Liste oder ein Dict wie Python aus ([1, 2], {'a': 1}) statt 1,2, sodass Chart-Skripte "data": {{ values }} verwenden können.
• apitemplate.io-Import: <script>- und <style>-Blöcke des CSS-Felds, die Template-Syntax enthalten, landen am Ende der Vorlage statt im Head-Tab, weil der Head nicht mit Daten gefüllt wird. Siehe Umstieg von apitemplate.io.

17. September 2026: Pakete 0.3.0

• Pakete 0.3.0: @formfeed/sdk, formfeed (Python), formfeed (CLI), @formfeed/engine, @formfeed/devkit, @formfeed/testing, @formfeed/mcp und n8n-nodes-formfeed mit allem vom 14. bis 16. September: Word- und PowerPoint-Vorlagen und die Umwandlung von Office-Dateien in PDF in den SDKs und der CLI, der apitemplate.io-Import mit API-Schlüssel, formfeed workspaces delete und output, das die Vorlage entscheidet.
• Vorlagenliste: Die Namensspalte hat Buttons zum Kopieren von Slug und Vorlagen-ID, den beiden Angaben, mit denen ein API-Aufruf eine Vorlage nennt. Dafür brauchen Sie weder das Zeilenmenü noch den Editor.
• Vorschau Fließend: Kopf- und Fußzeile stehen in den Seitenrändern, gemessen von den Seitenkanten, so wie Chromium sie druckt, statt über dem Inhalt. Die Seite entspricht jetzt der Vorschau Seiten.
• Passwort ändern: Das Benutzermenü hat den Eintrag Passwort ändern.
• Behoben: Die Vorschauen Seiten und Fließend im Editor ließen Seitenzahlen in Kopf- und Fußzeilen leer (Seite von); jetzt zeigen sie sie wie das PDF.
• Behoben: Der Batch-Dialog für Tabellen zeigte Ausgabe und Dateiname aus Spalte leer, bis Sie einen Wert wählten; jetzt stehen dort Wie die Vorlage und Zeilennummer.

16. September 2026: Word- und PowerPoint-Vorlagen

• Word- und PowerPoint-Vorlagen: Eine Vorlage kann eine .docx- oder .pptx-Datei mit Tags wie {{ customer.name }} im Text sein, in allen drei Vorlagensprachen. In Word setzen qrcode, barcode, epcQr, image und pageBreak Bilder und Seitenumbrüche; auf Folien werden Bilder zu Bildformen. chart, markdown und Includes lehnt die API mit unsupported_in_office (422) ab. Siehe Word- und PowerPoint-Vorlagen.
• In der App: Der Dialog zum Anlegen bietet eine Word-Vorlage aus einer Beispieldatei oder einem Upload und eine PowerPoint-Vorlage aus einer Beispielpräsentation oder einem Upload. Die Vorlagenseite zeigt die Datei, die Tags jedes Teils mit ihren Problemen, Datensätze, Einstellungen und Versionen, eine im Browser gefüllte Schnellvorschau und den Button Echtes Rendering.
• API: die Vorlagenarten docx und pptx. POST /templates und das Anlegen einer Version nehmen das Dokument als multipart/form-data; eine Version ohne Datei behält das letzte Dokument. GET /templates/{id}/versions/{which}/file lädt es herunter. Renderings dieser Vorlagen erzeugen output: "docx" bzw. "pptx" oder "pdf", und settings.office.output legt den Standard fest, wenn eine Anfrage keinen nennt.
• Pläne: Live-Renderings von Word- und PowerPoint-Vorlagen gibt es ab Starter. Im Free-Plan liefern Test-Renderings nur das markierte PDF, und eine Anfrage nach docx oder pptx beantwortet die API mit test_output_unavailable (403).
• Office zu PDF: POST /pdf/convert wandelt einen Upload aus Word, Excel, PowerPoint, OpenDocument oder RTF bis 20 MB, der nicht gespeichert wird, oder die Ausgabe eines Renderings einer Word- oder PowerPoint-Vorlage in PDF um, mit page_ranges, landscape und single_page_sheets. Auch HTML wird angenommen, weil Berichtsexporte es oft unter einem .doc-Namen speichern; verlinkte Bilder und Stylesheets bleiben leer. Ab dem Starter-Plan, gezählt wie ein PDF-Rendering. In der App: Office zu PDF auf der Seite Renderings. Siehe PDF-Tools.
• Neue Fehlercodes: file_type_unsupported (415), office_document_invalid, office_document_too_large und office_conversion_failed (422), office_unavailable (503, mit Retry-After). file_too_large und source_encrypted gelten auch für Vorlagendateien und Uploads zur Umwandlung.
• SDKs: docx und pptx bei den Ausgabeformaten und Vorlagenarten; templates.create() und templates.versions.create() (Python: create_version()) mit einer file; templates.versions.file() (Python: version_file()); pdf.convert() für einen Upload oder ein Rendering. Siehe TypeScript und Python.
• CLI: Ein Vorlagenordner kann template.docx oder template.pptx statt der HTML-Dateien enthalten. templates pull schreibt das Dokument der geholten Version, und push lädt es nur hoch, wenn es sich geändert hat; validate und dev listen die Funde nach Teil und Absatz; render, ci preview und dev füllen das Dokument lokal und wandeln es für PDF über die API um; test vergleicht das gefüllte XML mit .xml-Snapshots. formfeed pdf convert <Datei | Rendering-ID> wandelt jede angenommene Office-Datei um. QR-Codes, Barcodes und SVG-Bilder zeichnet das optionale Paket @resvg/resvg-js. Siehe Projektstruktur.
• apitemplate.io-Import mit API-Schlüssel: Vorlagen → Importieren → apitemplate.io → Mit API-Schlüssel listet alle Vorlagen des Kontos mit ihrer Gruppe und liest und prüft die gewählten PDF-Vorlagen in einem Durchgang; formfeed import apitemplate --all, --group <name> oder --template <id…> tut dasselbe mit --key (oder APITEMPLATE_API_KEY) und --source-region. Das JSON aus dem Editor von apitemplate.io wird zum Datensatz default des Entwurfs, Ränder ohne Einheit gelten als Pixel (auch im Kompatibilitätsendpunkt), Kopf- und Fußzeile behalten die Größe, in der apitemplate.io sie zeichnet, <link>- und <script>-Tags aus dem CSS-Feld kommen in den Head, und custom_header, custom_footer und die Textfelder werden zu Kopf- und Fußzeile. Siehe Von apitemplate.io migrieren.
• Mehrere Vorlagen archivieren und löschen: Wählen Sie Vorlagen in der Liste aus und archivieren Sie sie, mit Rückgängig; in der Ansicht Archiviert stellen Sie sie wieder her oder löschen sie als Inhaber oder Admin mit Endgültig löschen… nach einer getippten Bestätigung.
• Innenabstand von Kopf- und Fußzeile: settings.header.padding und settings.footer.padding (Standard 0 10mm) ersetzen den seitlichen Innenabstand der Box um Kopf- und Fußzeile von Chromium, damit Gestaltungen bis an den Rand reichen können; das Einstellungspanel bearbeitet sie als Innenabstand der Kopfzeile und Innenabstand der Fußzeile. Siehe Referenz der Einstellungen.
• Vorschauen wie das PDF: Die Vorschauen Fließend und Seiten zeichnen Kopf- und Fußzeile über die ganze Seitenbreite, Seiten setzt die Kopfzeile an die obere und die Fußzeile an die untere Kante, und Elemente der Vorlage behalten dort ihr eigenes Box-Modell, wie im PDF.
• Zoom in den Vorschauen: Strg+Mausrad, Zwei-Finger-Zoom und Strg+Plus, Minus und 0 zoomen die Vorschauen Fließend und Seiten und die Schnellvorschau von Word-Vorlagen, die dazu Buttons zum Vergrößern und Verkleinern und Einpassen hat.
• Rechnungs-E-Mail: Die Rechnungs-E-Mail der Organisation ist die Adresse, an die Stripe Rechnungen schickt (sonst die des ersten Inhabers), und zwar in beide Richtungen: Eine Änderung in der App erreicht Stripe, eine Änderung im Kundenportal kommt zurück. Auch Kontingent- und Abrechnungsmails gehen an sie. Der Checkout fragt die vollständige Rechnungsadresse ab.
• Erstattungen: Rechnungen auf der Seite Abrechnung zeigen Erstattet oder Teilweise erstattet.

15. September 2026: Workspaces löschen

• Workspace in der App löschen: Inhaber und Admins löschen einen Workspace unter Einstellungen → Workspaces, nachdem sie seinen Slug eingegeben haben. Er verschwindet sofort, seine API-Schlüssel funktionieren nicht mehr, und seine Vorlagen, Renderings, Ausgaben und Dateien werden nach 30 Tagen entfernt. Der Slug ist sofort wieder frei. Der letzte Workspace einer Organisation bleibt.
• Über die API: DELETE /workspaces/{id} löscht jeden Workspace der Organisation des Schlüssels, zum Beispiel Vorschau-Workspaces pro Branch, die ein CI-Job aufräumt. formfeed workspaces delete <id> --yes in der CLI, workspaces.delete() in TypeScript und Python.
• Neuer Scope: workspace:delete, nicht standardmäßig in neuen Schlüsseln und nie in CLI-Anmeldeschlüsseln. Siehe Scopes.
• Neuer Fehlercode: last_workspace (409).

15. September 2026: Scopes und Standardausgabe

• Ein Schreib-Scope enthält seinen Lese-Scope: template:write fügt template:read hinzu, file:write fügt file:read hinzu und render:create fügt render:read hinzu, weil Schreibzugriffe mit dem Objekt antworten und asynchrone Renderings abgefragt werden. Bestehende Schlüssel wurden ergänzt. Der Schlüssel-Dialog zeigt jeden enthaltenen Scope unter seinem Schreib-Scope, angehakt und gesperrt. Siehe Scopes.
• Scopes der Dateibibliothek in der App: Der Dialog zum Anlegen eines Schlüssels bietet file:read und file:write an, damit Schlüssel aus der App Dateien hochladen können; die Upload-Aktionen von Zapier und Make scheiterten bisher mit 403.
• Die Vorlage entscheidet über die Ausgabe: Ein Rendering ohne output erzeugt bei PDF-Vorlagen ein PDF und bei Bildvorlagen das Format aus settings.image.format der Vorlage (ohne Angabe PNG); bisher renderten Bildvorlagen dann ein PDF. POST /renders/batch nimmt ein output auf oberster Ebene für seine Einträge, und der Batch-Dialog für Tabellen steht standardmäßig auf Wie die Vorlage; bisher renderte er jeden Batch als PDF. CLI, MCP, n8n, Zapier und Make lassen output weg, solange Sie keins wählen. Siehe Rendering.

14. September 2026: Bausteine im Editor

• Panel Bausteine: Der Button Bausteine im Editor öffnet neben dem Code ein Panel mit Suche, einer Live-Vorschau jedes Bausteins und jedem Baustein als Befehl in der Palette. Beim Einfügen kommen die Beispieldaten des Bausteins, nur die CSS-Regeln, die Ihrem Stylesheet fehlen, und seine Beschriftungen auf Englisch und Deutsch in das Panel Übersetzungen; Fußzeilen-Bausteine kommen in den Tab Fußzeile. Siehe Bausteine.
• Neue Bausteine: Briefkopf und rechtlicher Fußtext aus dem Brand Kit, Anschriftfeld für Fensterumschläge (DIN 5008), Informationsblock, Rechnungsüberschrift mit Leistungszeitraum, Zahlungsbedingungen und Bankverbindung, Hinweis Kleinunternehmer (§ 19 UStG), Hinweis Reverse Charge, Zusammenhalten, Seitenumbruch und Kennzahlen. Die bestehenden Bausteine lesen die Farben des Brand Kits und beschriften ihre Überschriften mit t.
• Diagramme aus einfachen Daten: chart zeichnet aus labels mit values oder mehreren series mit label, values und color. Eine Integration sendet also Zahlen statt einer Chart.js-Konfiguration. Reihen und Segmente ohne Farbe nehmen eine feste Palette, eine einzelne Reihe ohne Namen zeigt keine Legende. Eine vollständige Konfiguration mit data und options funktioniert weiterhin. Der Baustein Diagramm nutzt das mit der primären Farbe des Brand Kits.
• Partials der Organisation erscheinen im Panel, werden als Include eingefügt und in der Vorschau mit den Daten der Vorlage gezeigt.
• Behoben: Der Baustein Rechnungstabelle zeigte in Handlebars-Vorlagen leere Zellen.
• Behoben: Die Seite Partials und die Vervollständigung im Editor schrieben Liquid-Includes als {% render "name" %}. Damit sieht das Partial nur brand, nicht die Daten der Vorlage. Beide schreiben jetzt {% include "name" %}, und die Dokumentation sagt es. Liquid-Vorlagen, die ein geteiltes Partial schon mit render einbinden, sollten auf include wechseln, wenn das Partial Daten der Vorlage liest.

13. September 2026: lokale Webhooks und nachstellbare Renderings

• Render-Anfragen aufbewahren: eine neue Workspace-Einstellung, standardmäßig aus. Mit 24 Stunden (ab Starter) oder 7 Tagen (ab Pro) wird die Anfrage jedes Renderings, synchron und asynchron, nach dem Ende des Renderings aufbewahrt; der Plan begrenzt die Wahl. Bisher wurden asynchrone Anfragen in jedem Plan 24 Stunden aufbewahrt und synchrone gar nicht. Passwörter der Nachbearbeitung werden nie aufbewahrt, deshalb wird ein passwortgeschütztes Rendering nicht aus dem Render-Protokoll erneut gerendert. Siehe Datenresidenz.
• Ein fehlgeschlagenes Rendering nachstellen: GET /renders/{id}/input liefert die aufbewahrte Anfrage eines Renderings (Vorlage und Version, Daten, Locale, Optionen), und formfeed renders pull <render id> schreibt ihre Daten als Datensatz ins Projekt, mit --run, um lokal zu rendern und Zeile und Spalte des Fehlers zu zeigen, --snapshot, um aus einem guten Rendering einen Test zu machen, und --redact, um personenbezogene Daten unter Erhalt der Form zu ersetzen. Jeder Lesezugriff wird protokolliert. Siehe Ein fehlgeschlagenes Rendering nachstellen.
• Webhooks lokal entwickeln: formfeed listen --forward-to http://localhost:3000/webhooks leitet die Webhook-Ereignisse des Workspace über einen WebSocket, den die CLI öffnet, an einen lokalen Server weiter, signiert mit einem Geheimnis, das für einen API-Schlüssel über Sitzungen hinweg gleich bleibt, mit den normalen Wiederholungen und dem Zustellprotokoll. Nur Test-Ereignisse, außer mit --live; drei Sitzungen pro Workspace. formfeed trigger render.completed --template <slug> rendert wirklich mit einem Test-Schlüssel, damit ein echtes Ereignis entsteht. Siehe Webhooks lokal entwickeln.
• Ereignisse erneut senden: POST /webhooks/events/{id}/resend sendet ein gespeichertes Ereignis erneut an einen registrierten Endpunkt oder eine Listen-Sitzung, auch bereits zugestellte Ereignisse; in der CLI formfeed webhooks resend <evt_id>.
• Umgebungen für Endpunkte: Webhook-Endpunkte nehmen environments an (live, test oder beide, der Standard), damit ein Staging-Empfänger keine Produktions-Renderings mehr sieht. Siehe Test- und Live-Ereignisse.
• Neue Scopes: render:input und webhook:listen, standardmäßig nicht in neuen Schlüsseln; formfeed login gibt sie Editoren, Admins und Inhabern. Siehe Scopes.
• Neue Fehlercodes: render_input_expired (410), listen_session_limit (409) und listen_session_ended (410).
• SDKs: renders.input(), webhooks.resend() und webhooks.listen.start() / end() in TypeScript und Python; Endpunkte nehmen environments an.

13. September 2026: Release Channels und typisierte Vorlagen

• Release Channels: benannte Zeiger von einer Vorlage auf eine Version, etwa staging, neben published. Renderings wählen einen mit "version": "staging" (Live- und Test-Schlüssel), und das template des Renderings erhält channel und canary, in der API und in Webhooks. Channels verschieben, promoten, zurückrollen und löschen Sie im Panel Versionen des Editors, mit PUT /templates/{id}/channels/{name} und den Endpunkten promote und rollback oder mit der CLI. Canary-Releases schicken 1 bis 50 Prozent der Renderings eines Channels an eine zweite Version, gewählt anhand des Idempotency-Key. Verschiebungen erreichen Renderings innerhalb einer Minute. Starter hat 2 Channels pro Vorlage, Pro und Business 10 sowie Canaries. Siehe Release Channels.
• Schema-Prüfung beim Veröffentlichen: Veröffentlichen, Verschieben eines Channels, Promoten und Zurückrollen vergleichen das Datenschema der Version, die live geht, mit dem, das Aufrufer gerade verwenden. Speichern beide ein Schema, antwortet eine brechende Änderung (ein neues Pflichtfeld, ein engerer Typ, ein entfernter Enum-Wert) mit 409 schema_breaking_change, außer die Anfrage sendet allow_breaking: true; bei abgeleiteten Schemas ist das Ergebnis eine Warnung. Antworten zum Veröffentlichen und zu Channels enthalten schema_check. Der Editor veröffentlicht jetzt über die API und listet brechende Änderungen vor dem Veröffentlichen, mit Publish anyway.
• Store as contract: Der Schema-Bereich des Editors leitet ein Schema über alle Datensätze ab (ein Feld, das nur einige Datensätze enthalten, ist optional) und speichert es mit der nächsten Version, mit einem Pflicht-Schalter pro Feld.
• Typisierte Vorlagendaten: formfeed types erzeugt TypeScript (formfeed.d.ts, erweitert @formfeed/sdk) oder Python (formfeed_templates.py, ein TypedDict pro Vorlage und typed(client)) aus gespeicherten oder abgeleiteten Schemas, und formfeed types --check lässt die CI scheitern, wenn die Datei veraltet ist. Im TypeScript-SDK prüfen renders.create und renders.batch die data der Vorlagen, die die Datei kennt. Siehe Typisierte Vorlagendaten.
• Neue Fehlercodes: channel_not_found (404), channel_name_invalid (422), channel_in_use (409) und schema_breaking_change (409). Ein benannter Channel im Free-Plan oder ein Canary unterhalb von Pro antwortet mit 403 forbidden und feature: "channels" oder feature: "canary".
• CLI: formfeed types, formfeed channels list|set|promote|rollback|delete, templates push --channel <name> und --allow-breaking; formfeed.json nimmt Standardwerte unter types an.
• SDKs: templates.channels.list(), set(), promote(), rollback() und delete(), allowBreaking / allow_breaking beim Veröffentlichen und Channel-Namen in versions.get / version(), in TypeScript und Python. Das TypeScript-SDK exportiert FormfeedTemplates, TemplateData, TypedRenderRequest, Channel, ChannelList und SchemaCheck.

13. September 2026

• Brand Kit: eines pro Organisation, in jedem Plan. Auf der neuen Seite Marke legen Sie Firmenname, rechtlichen Fußtext, Farb-Tokens, Schriften für Überschriften und Fließtext, Grundgröße, drei Logos sowie Papier und Ränder für neue Vorlagen fest. Vorlagen lesen es als brand ({{ brand.logo.primary }}, {{ brand.legal_footer }}) und als CSS-Variablen (--brand-color-primary, --brand-font-heading); Logos funktionieren auch in Kopf- und Fußzeilen. Änderungen erreichen veröffentlichte Vorlagen ohne neues Veröffentlichen. GET /brand liest es.
• Geteilte Partials: Briefköpfe, Fußzeilen und andere Fragmente für die ganze Organisation auf der neuen Seite Partials, per Name eingebunden wie Partials der Vorlage und nach ihnen aufgelöst. Beim Bearbeiten zeigt die App, welche Vorlagen sich ändern. API: GET, PUT und DELETE /partials/{name} mit Konflikterkennung über base_version; bis zu 200 pro Organisation. Siehe Geteilte Partials.
• Pro Rendering festgehalten: Jedes Rendering hält die Version des Brand Kits und die Versionen der verwendeten geteilten Partials fest, und die Deduplizierung verwendet ein Ergebnis nur wieder, wenn sie unverändert sind.
• Behoben: Das echte Rendering im Editor enthält jetzt die Schriften der Organisation; bisher schickte es keine mit, Eine Vorlage mit Schriften, die unter Schriften hochgeladen sind, wurde dort deshalb mit Ersatzschriften gedruckt, anders als bei API-Renderings.
• CLI: formfeed brand pull speichert das Kit in .formfeed/brand.json für dev, render, test und ci preview; formfeed partials list|pull|push gleicht geteilte Partials mit dem Ordner partials/ des Projekts ab, mit --engine, --dry-run und --force sowie Exit-Code 2 bei einem Konflikt. formfeed templates push lässt geteilte Partials aus der Version heraus.
• SDKs: brand.get() sowie partials.list(), get(), put() und delete() in TypeScript und Python.
• Serverseitige Validierung: POST /templates/{id}/validate prüft eine Version mit Daten, ohne zu rendern: Syntax, Kopf- und Fußzeile, fehlende Partials, Laufzeitfehler und die Daten gegen das gespeicherte Schema. Kostenlos.
• validate_data: true bei Renderings und Batch-Einträgen prüft die Daten zuerst gegen das gespeicherte Schema der Vorlage und antwortet mit 422 data_validation_error samt errors-Liste, bevor etwas gerendert oder gezählt wird. Diagnosen haben für Datenfehler jetzt path.
• Kein dokumentierter Endpunkt und keine Option antwortet mehr mit 501 not_implemented.
• Jinja2-Kompatibilität: .format() versteht Python-Formatangaben ("{:,.2f}", verschachtelte Felder); namespace() und {% set ns.total = … %} funktionieren; truncate, map(attribute=…), selectattr und rejectattr nehmen ihre Jinja2-Argumente. Der Editor warnt nicht mehr bei Makro-Argumenten, True oder einem Schleifennamen, den zwei Schleifen verwenden.
• Behoben: Aus apitemplate.io importierte Vorlagen mit einem namespace()-Zähler scheiterten mit „Cannot read properties of undefined“, und die versteckten Schleifen-Wrapper des visuellen Editors erschienen als leere Tabellenzeilen.
• Behoben: Das Speichern oder Importieren einer Vorlage mit einem <script>-Tag scheiterte in der App mit „Http failure response … 0 undefined“. Die App speichert Versionen jetzt über die API; POST /templates/{id}/versions nimmt data_sets an.
• Pakete 0.2.0: @formfeed/sdk, formfeed (Python), formfeed (CLI), @formfeed/engine, @formfeed/devkit, @formfeed/testing, @formfeed/mcp und n8n-nodes-formfeed mit allem oben Genannten und vom 12. September.

12. September 2026

• Dateibibliothek: Bilder und PDFs mit POST /files hochladen, auflisten, lesen und löschen und über ihren Namen mit asset('logo.png') verwenden; auch relative Bildpfade werden gegen die Bibliothek aufgelöst. Neue Scopes file:read und file:write; file:delete gilt jetzt auch für Dateien der Bibliothek. Neuer Fehler file_too_large (413).
• PDF-Post-Processing: Bild-Wasserzeichen (watermark.image, ein PNG oder JPEG der Bibliothek) und PDFs der Bibliothek als Merge-Quellen (merge_after, /pdf/merge), über Namen oder fil_…-ID.
• WebP-Ausgabe: "output": "webp", mit image.quality (100 ist verlustfrei).
• SDKs: client.files in TypeScript und Python; Wasserzeichen nehmen image, Merges nehmen Dateien der Bibliothek.
• CLI: formfeed files list|push|pull|delete mit einem Ordner files/ im Projekt, formfeed dev liefert diesen Ordner aus, damit asset() offline funktioniert, und render sowie ci preview lösen asset() gegen die Bibliothek des Workspace auf. render --output webp.
• Integrationen: Upload File in n8n und Zapier; Upload a File, List Files und Delete a File in Make; WebP überall als Ausgabeformat.
• Behoben: Gelöschte und abgelaufene Ausgaben werden jetzt aus dem Speicher entfernt; dem Aufräumen fehlte seit dem 11. September eine Datenbankberechtigung.

Private Beta, September 2026

Die erste Version, die Beta-Workspaces zur Verfügung steht.

• API: synchrone und asynchrone Renderings aus Vorlagen, HTML und URLs; Batches mit bis zu 1.000 Renderings und optionalem Zip; Webhooks mit Signaturen und Wiederholungen; Idempotenz-Schlüssel, Deduplizierung und der Fallback von synchron auf asynchron; Vorlagen und Versionen; Verbrauch; die Kompatibilitätsendpunkte für apitemplate.io.
• PDF-Post-Processing: PDFs zusammenführen, Passwortschutz (AES-256) und Text-Wasserzeichen, als post-Block eines Renderings oder über /pdf/merge, /pdf/protect, /pdf/watermark, dazu das kostenlose /pdf/info. Ab dem Starter-Plan.
• Vorlagen: Jinja2-kompatibel, Liquid und Handlebars mit einem gemeinsamen Satz von Helfern, darunter QR-Codes, Barcodes, SEPA-Zahlungscodes, Diagramme und Tailwind.
• Tools: der Web-Editor mit Autovervollständigung und paginierter Vorschau; die formfeed-CLI mit lokaler Vorschau, Validierung, Snapshot-Tests und CI-Vorschauen; Importer für apitemplate.io, PDFMonkey und jsreport.
• Pakete: @formfeed/sdk, formfeed (Python), @formfeed/engine, @formfeed/testing, @formfeed/devkit, @formfeed/mcp, n8n-nodes-formfeed.
• Region: EU (Frankfurt).