Zum Inhalt springen

Rate Limits

Frontmail begrenzt, wie schnell Anfragen gesendet werden können – um Ihre Credits vor Missbrauch und Ihre Anbieter vor Lastspitzen zu schützen. Die Limits werden in festen Zeitfenstern gezählt (eine Sekunde bei den Limits für Tarif und Schlüssel, ein von Ihnen gewähltes Fenster beim Limit pro IP).

Alle Anfragen einer Organisation zusammen – mit öffentlichem und privatem Schlüssel – teilen sich ein Limit, das vom Tarif abhängt:

TarifAnfragen pro Sekunde (pro Organisation und pro Schlüssel)Testversände / Tag
Free220
Starter520
Pro2020
Business 50k5020
Business 100k5020
Business 200k5020

Eine Batch-Anfrage zählt für das Rate Limit als eine Anfrage, aber jede Nachricht darin verbraucht einen Credit – verwenden Sie für Massenversand von Servern /v1/send-batch.

Anfragen mit öffentlichem Schlüssel werden zusätzlich pro Client-IP begrenzt, damit ein einzelner Besucher oder Bot nicht das Limit Ihrer Organisation aufbrauchen kann. Standard sind 10 Anfragen pro 60 Sekunden pro IP. Inhaber und Admins ändern das unter Sicherheit → Rate Limit pro IP mit zwei Feldern, Anfragen und Pro (Sekunden) – die Seite fasst es zusammen als Höchstens N Anfragen pro M Sekunden von einer IP-Adresse. Anfragen mit privatem Schlüssel werden nicht pro IP begrenzt. IPv6-Clients werden pro /64-Netz gezählt (der Block, den ein einzelner Heim- oder Serveranschluss üblicherweise erhält), wechselnde Adressen innerhalb davon helfen einem Bot also nicht. Die Client-Adresse stammt vom CDN von Frontmail; Anfragen, die es umgehen wollen, werden abgelehnt.

Anfragen werden außerdem pro Schlüssel gezählt, mit demselben Limit pro Sekunde wie Ihr Tarif.

Bei Anfragen mit öffentlichem Schlüssel zählen die Limits für Tarif und Schlüssel (und die Anomalieerkennung) nur Anfragen, die die Vorlagensuche und – sofern die Vorlage es verlangt – die CAPTCHA-Prüfung bestanden haben. Eine Flut ungültiger Anfragen (unbekannte template_id, fehlender Turnstile-Token) wird abgelehnt, ohne das Limit aufzubrauchen, das Ihre echten Besucher brauchen; für solche Anfragen gilt nur ein großzügiger Flutschutz (mindestens 50 Anfragen pro Sekunde und Organisation). Geben Sie jedem Server oder Job einen eigenen privaten Schlüssel: Verhält sich einer daneben, sehen Sie das unter Sicherheit → Private Schlüssel (Zuletzt verwendet) und widerrufen genau diesen Schlüssel.

Die API antwortet mit 429 rate_limited und einem Retry-After-Header in Sekunden. Die SDKs warten und wiederholen automatisch, wenn Retry-After höchstens 60 Sekunden beträgt. Gedrosselte Anfragen verbrauchen keine Credits.

HTTP/1.1 429 Too Many Requests
Retry-After: 2
{ "error": { "code": "rate_limited", "message": "Too many requests.", "docs_url": "https://docs.frontmail.dev/reference/errors/#rate-limited" } }

Auch Ihr E-Mail-Anbieter hat eigene Limits (Amazon SES im Sandbox-Modus erlaubt z. B. 1 Nachricht pro Sekunde). Der Versand hält sie ein, indem er die Zustellung taktet – das verzögert Nachrichten, lehnt Ihre Anfragen aber nicht ab.

  • Die Anomalieerkennung bremst plötzliche, ungewöhnliche Spitzen von Anfragen mit öffentlichem Schlüssel auf eine Anfrage alle zwei Sekunden.
  • Vorsignierte Uploads mit dem öffentlichen Schlüssel (POST /v1/uploads) haben ein tägliches Byte-Budget pro Organisation (200 × das Anhangslimit Ihres Tarifs).
  • Die SDK-Option limitRate drosselt einen einzelnen Browser (siehe Bot-Schutz).
  • Die Edge (CloudFront + AWS WAF) blockiert Fluten, bevor sie die API erreichen.
  • Das Dashboard hat eigene Limits pro Nutzer, z. B. 10 Testversände pro Minute zusätzlich zum täglichen Testversand-Limit des Tarifs aus der Tabelle oben.