Changelog

Hier finden Sie Änderungen, die die öffentliche API oder die SDKs betreffen. Die SDK-Pakete folgen Semantic Versioning; ihre ausführlichen Changelogs erscheinen mit jedem Release auf npm.

Noch nicht veröffentlicht – öffentliche Beta

SendGrid wird nicht mehr unterstützt (Oktober 2026)

Seit dem 1. Oktober 2026 steht SendGrid nicht mehr als E-Mail-Anbieter zur Verfügung. Wenn Sie über einen SendGrid-Dienst versendet haben, wechseln Sie zu einem anderen API-Anbieter wie Resend, Postmark, Mailgun, Brevo oder Mailjet und wählen Sie den neuen Dienst anschließend in Ihren Vorlagen aus (auch als Ersatzdienst, falls Sie ihn dort genutzt haben).

Übersetzungen von Vorlagen (September 2026)

Eine Vorlage lässt sich jetzt in vielen Sprachen versenden – siehe Übersetzungen von Vorlagen.

• Dashboard: eine Leiste Sprachen im Vorlagen-Editor. Fügen Sie pro Vorlage bis zu 29 Sprachvarianten hinzu (jede BCP-47-Sprache, z. B. hu oder pt-BR) – als Kopie der Standardsprache, leer oder per maschineller Übersetzung. Varianten übersetzen Betreff, HTML, Text und Absendername; Empfänger, Parameter und Einstellungen bleiben gemeinsam. Jede Variante hat eigene Versionen samt Rollback sowie die Kennzeichnungen Veraltet / Maschinell. Die Standardsprache der Vorlage kann jede beliebige Sprache sein (Einstellungen → Allgemein → Standardsprache). Export und Import enthalten die Varianten.
• Maschinelle Übersetzung mit eigenem Schlüssel: OpenAI, Anthropic, Google Gemini oder DeepL mit dem eigenen API-Schlüssel Ihrer Organisation (Einstellungen → Maschinelle Übersetzung, Inhaber und Admins). Frontmail prüft, dass Parameter, Links und HTML-Struktur erhalten bleiben (translation_invalid). 30 Übersetzungen pro Stunde und Organisation, bis zu 60.000 Zeichen. Neue Fehlercodes translation_not_configured, translation_invalid, translation_provider_auth, translation_provider_error.
• API: optionales locale in POST /v1/send und in den Einträgen von /v1/send-batch, Formularfeld fm_locale in POST /v1/send-form (ein Feld namens locale bleibt ein Vorlagenparameter). Auflösung: exakte Sprache → gleiche Basissprache (de-AT → de) → Standardsprache; ein fehlerhaftes Tag ergibt 400 invalid_body. Sendeantworten und Batch-Ergebnisse geben das verwendete locale zurück; GET /v1/templates liefert locales. Automatische Antworten folgen der Sprache der ursprünglichen Nachricht, Erneut senden behält sie bei. Die EmailJS-kompatiblen Routen verwenden immer die Standardsprache.
• Formatierung: Datum, Zahlen, Beträge und die Fußzeile im Free-Tarif richten sich jetzt nach der Sprache, in der die E-Mail versendet wird (bisher nach der Sprache der Organisation).
• JavaScript-SDKs (nächstes Release, 0.2.0 – zusammen mit der Sicherheitshärtung der SDKs weiter unten): Option locale in send / sendForm (von sendForm als fm_locale gesendet), Prop locale an <FrontmailForm> (React, Vue, Svelte) und use:frontmailForm, result.locale; @frontmail/node: locale bei send / in den Einträgen von sendBatch, templates.list() liefert locales, und frontmail types gibt die Sprachen jeder Vorlage sowie einen Typ <TemplateName>Locale aus. @frontmail/emailjs-compat bleibt unverändert (nur Standardsprache).
• Android-/Kotlin-SDK 0.2.0: SendOptions(locale = "de"), SendResult.locale.
• iOS-/Swift-SDK 0.2.0: SendOptions(locale: "de"), SendResult.locale.

Sicherheitshärtung: Edge der öffentlichen API und Schlüssel (September 2026)

Geändertes Verhalten – bitte prüfen Sie Ihre Integration:

• Anfragen ohne Origin und Referer (Server, curl, native Apps) mit dem öffentlichen Schlüssel brauchen jetzt Mobile Apps erlauben – auch wenn Ihre Liste erlaubter Websites leer ist. Bisher hat eine leere Liste sie akzeptiert. Bei Organisationen, die solche Anfragen in den letzten 30 Tagen gesendet haben, wurde der Schalter automatisch eingeschaltet. Andernfalls: 403 origin_not_allowed (details.reason: "no_origin"). Verwenden Sie auf Servern einen privaten Schlüssel.
• Private Schlüssel aus dem Browser werden abgelehnt: Eine Anfrage mit privatem Schlüssel (Authorization: Bearer oder das EmailJS-artige Feld accessToken), die einen Origin-Header trägt, erhält den neuen Fehler 403 private_key_in_browser. Für interne Tools lässt sich das freischalten: Sicherheit → Private Schlüssel im Browser erlauben.
• CAPTCHA bei Anfragen ohne Origin wird nur dann mit Frontmails gemeinsamem Mobile-Widget geprüft, wenn Mobile Apps erlauben eingeschaltet ist. Testschlüssel von Cloudflare werden in der Produktion abgelehnt.
• Statusabfrage: Senden Sie das Status-Token im Header X-Frontmail-Status-Token; ?token= funktioniert für ältere SDKs weiterhin.
• Rate Limits: IPv6-Clients teilen sich das Limit pro IP je /64-Netz. Die Limits pro Schlüssel und Organisation sowie die Anomalieerkennung zählen jetzt nur noch Anfragen, die die Vorlagen- und CAPTCHA-Prüfung bestanden haben – eine Flut ungültiger Anfragen blockiert Ihre echten Besucher also nicht mehr.
• Anhänge: Dateinamen werden bereinigt (unsichtbare und Bidi-Zeichen, Punkte am Ende), und weitere gefährliche Typen werden abgelehnt (HTML, SVG, Disk-Images, OneNote, Office mit Makros, .url, .lnk, …). Uploads mit öffentlichem Schlüssel (POST /v1/uploads) brauchen eine Vorlage, die Anhänge akzeptiert, und haben ein tägliches Datenvolumen pro Organisation.
• template_id / service_id mit mehr als 64 Zeichen in Multipart-Anfragen → 400 invalid_body (bisher 500).
• Die API, die Dashboard-API und die Anmeldung akzeptieren nur noch Traffic, der über das CDN von Frontmail kommt.

API

• POST /v1/send, /v1/send-form, /v1/send-batch, /v1/uploads, GET /v1/messages/:id, GET /v1/history, GET /v1/templates und EmailJS-kompatible Aliase.
• Einheitliches Fehlerformat mit docs_url; Unterstützung für Idempotency-Key (24 h).
• Warteschlange zurückgehaltener E-Mails mit den Status held / held_service_error und den Modi hold / reject.
• Inhaltssperre für Versände mit öffentlichem Schlüssel an Vorlagen mit dynamischem Empfänger: CAPTCHA ist Pflicht (dynamic_recipient_requires_captcha), feste Absenderfelder (dynamic_field_not_allowed), keine HTML-Parameter und Texte mit höchstens 500 Zeichen, Links nur zu erlaubten Domains (link_not_allowed) und höchstens 5 E-Mails pro Empfänger und Tag. Eine From-Adresse aus Parametern wird bei jedem Versand mit öffentlichem Schlüssel abgelehnt. Auch automatische Antworten sind gesperrt. Neue Einstellungen: security.allowedLinkDomains, security.recipientDailyLimit, in der Vorlage enforceLinkAllowlist. Siehe Erlaubte Links und Inhaltssperre.

SDKs

• @frontmail/browser 0.x (ESM + UMD, Version mit SRI festlegen), @frontmail/react, @frontmail/react-native, @frontmail/vue, @frontmail/svelte, @frontmail/node mit dem CLI frontmail types, @frontmail/emailjs-compat.
• Automatische Wiederholungen mit exponentiellem Backoff und Idempotency Keys; typisierte Fehler.

Sicherheit

• Die Zwei-Faktor-Authentifizierung gilt jetzt für jede Anmeldemethode – auch für Anmeldelinks per E-Mail und Google / GitHub – und lässt sich nur mit bestätigter E-Mail-Adresse einschalten.
• Anmelde- und Bestätigungslinks, die in einem anderen Browser geöffnet werden, verlangen eine Bestätigung (oder melden diesen Browser nicht an) – ein Link von jemand anderem kann Sie also nicht in dessen Konto anmelden.
• Das Ändern der Anmelde-E-Mail erfordert Ihr Passwort und die Zustimmung über die bisherige Adresse.
• Admins können die Rolle Abrechnung nicht mehr vergeben; nur der Inhaber verwaltet Admins und Mitglieder mit der Rolle Abrechnung.
• Webhook-URLs der Anbieter sind für Betrachter und Mitglieder mit der Rolle Abrechnung verborgen und lassen sich neu erzeugen (Neue Webhook-URL erzeugen).
• Eigene SMTP-Server müssen eine öffentliche Adresse und Port 25, 465, 587 oder 2525 verwenden.
• Anhänge von Vorlagen dürfen nur Dateien verwenden, die dieselbe Organisation hochgeladen hat.
• Team-Einladungen sind pro Empfänger und Organisation begrenzt; Organisationsnamen dürfen keine Links enthalten.
• An die Analyse exportierte Klickdaten enthalten keine Query-Strings mehr (Tokens, E-Mails).

Sicherheitshärtung der SDKs (nächstes SDK-Release, 0.2.0)

• Breaking Change: Die Browser-SDKs (@frontmail/browser, React, Vue, Svelte, @frontmail/emailjs-compat) werfen private_key_in_browser, wenn in einem Webbrowser ein privater Schlüssel (privateKey, in compat accessToken) verwendet wird; @frontmail/node verweigert dort den Start. Abschalten: dangerouslyAllowPrivateKeyInBrowser: true.
• sendForm überspringt Passwortfelder, Anti-CSRF-Felder und reservierte Namen; neu ist formFields: { include, exclude }.
• getStatus sendet das Status-Token im Header X-Frontmail-Status-Token statt in ?token=.
• <TurnstileWebView> in React Native ist auf die Widget-Seite beschränkt (Origins, Navigation, Nachrichten).
• CDN: Neben jedem versionierten Bundle liegt sri.json mit integrity-Hashes; die Dokumentation verwendet URLs mit fester Version und Subresource Integrity.

Dashboard

• HTML-Vorlagen-Editor mit Live-Vorschau, typisierten Parametern, Prüfungen, Versionen und Galerie (EN/CS).
• E-Mail-Dienste für SMTP, Mailgun, Amazon SES, Postmark, SendGrid, Mailjet, Brevo, Resend, Gmail und Outlook / Microsoft 365, mit Failover und Health-Checks.
• Credits: Tarife, Credit-Pakete, Überziehung, automatische Aufladung; Nutzungsstatistiken.

Abrechnung und Credits (Sicherheitskorrekturen)

• Jahrestarife erhalten ihr Monatskontingent und den Überziehungspuffer jetzt in jedem Monat des Zeitraums (bisher nur im ersten Monat).
• Bei Jahrestarifen wird die genutzte Überziehung monatlich mit einer separaten Rechnung abgerechnet; Überziehung, die vor dem Ende eines Abonnements genutzt wurde (Kündigung, Löschen der Organisation), wird sofort abgerechnet.
• Beim Wechsel von monatlicher zu jährlicher Abrechnung werden die im laufenden Monat verbrauchten Credits übernommen.
• Tarifwechsel werden abgelehnt, solange das Abonnement eine unbezahlte Rechnung hat (409 conflict, details.reason: "subscription_not_active").
• Angefochtene Zahlungen (Chargebacks) entziehen die damit gekauften Credits; wird der Streitfall gewonnen, werden sie wiederhergestellt. Erstattungen werden einzeln verarbeitet.
• Neu: Die Warteschlange zurückgehaltener E-Mails ist pro Organisation begrenzt; darüber hinaus erhalten Anfragen 402 insufficient_credits mit details.reason: "hold_queue_full".
• Neu: E-Mails, die mit dem öffentlichen Schlüssel gesendet werden, nutzen weder die Überziehung noch lösen sie eine automatische Aufladung aus, sofern Sie das nicht unter Abrechnung → Credits kaufen → Ausgaben durch Traffic mit öffentlichem Schlüssel einschalten (standardmäßig aus, auch für bestehende Organisationen).
• Eigene SMTP-Server: Fehler, nachdem der Server die Nachricht angenommen hat, werden nicht mehr erstattet; eine Schutzgrenze pro Organisation stoppt Erstattungen, wenn Fehler ungewöhnlich häufig auftreten.
• Webhooks der Anbieter setzen nur tatsächliche Empfänger der Nachricht auf die Sperrliste; Amazon-SES-Webhooks merken sich das SNS-Topic der ersten signierten Nachricht. Erneut senden lehnt Vorlagen ab, die nach einem Downgrade eingefroren wurden.