Rate limits

Frontmail limite la vitesse à laquelle les requêtes peuvent être envoyées, pour protéger vos crédits contre les abus et vos fournisseurs contre les rafales. Les limites sont comptées dans des fenêtres de temps fixes (une seconde pour les limites du forfait et des clés, une fenêtre que vous choisissez pour la limite par IP).

Par organisation (forfait)

Toutes les requêtes d’une organisation réunies – clé publique et clé privée – partagent une limite qui dépend du forfait :

Forfait	Requêtes par seconde (par organisation et par clé)	Envois de test / jour
Free	2	20
Starter	5	20
Pro	20	20
Business 50k	50	20
Business 100k	50	20
Business 200k	50	20

Une requête groupée compte comme une seule requête pour le rate limit, mais chaque message qu’elle contient consomme un crédit – utilisez /v1/send-batch pour les envois en masse depuis vos serveurs.

Par adresse IP

Les requêtes avec clé publique sont aussi limitées par adresse IP du client, pour qu’un seul visiteur ou bot ne puisse pas épuiser la limite de votre organisation. La valeur par défaut est de 10 requêtes par 60 secondes et par IP. Les propriétaires et les administrateurs la modifient dans Sécurité → Rate limit par IP avec deux champs, Requêtes et Par (secondes) – la page la résume sous la forme Au maximum N requêtes toutes les M secondes depuis une même adresse IP. Les requêtes avec clé privée ne sont pas limitées par IP. Les clients IPv6 sont comptés par réseau /64 (le bloc qu’obtient généralement une connexion domestique ou un serveur), si bien que changer d’adresse à l’intérieur de ce bloc n’aide pas un bot. L’adresse du client est fournie par le CDN de Frontmail ; les requêtes qui tentent de le contourner sont refusées.

Par clé

Les requêtes sont aussi comptées par clé, avec la même limite par seconde que votre forfait.

Pour les requêtes avec clé publique, les limites du forfait et des clés (ainsi que la détection des anomalies) ne comptent que les requêtes qui ont passé la recherche du modèle et – lorsque le modèle l’exige – la vérification CAPTCHA. Un afflux de requêtes invalides (template_id inconnu, jeton Turnstile manquant) est refusé sans épuiser la limite dont vos vrais visiteurs ont besoin ; seule une protection anti-inondation généreuse (au moins 50 requêtes par seconde et par organisation) s’applique à ces requêtes. Donnez à chaque serveur ou tâche sa propre clé privée : si l’un d’eux se comporte mal, vous le voyez dans Sécurité → Clés privées (Dernière utilisation) et vous pouvez révoquer uniquement cette clé.

Quand vous atteignez une limite

L’API répond 429 rate_limited avec un en-tête Retry-After en secondes. Les SDK attendent et relancent automatiquement la requête lorsque Retry-After ne dépasse pas 60 secondes. Les requêtes limitées ne consomment pas de crédits.

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" } }

Votre fournisseur d’e-mail a aussi ses propres limites (par exemple, Amazon SES en mode sandbox autorise 1 message par seconde). L’expéditeur les respecte en étalant la livraison – cela retarde les messages mais ne refuse pas vos requêtes.

Autres protections

La détection des anomalies ralentit les pics soudains et inhabituels de requêtes avec clé publique à une requête toutes les deux secondes.
Les uploads présignés avec la clé publique (POST /v1/uploads) ont un budget quotidien d’octets par organisation (200 × la limite de pièces jointes de votre forfait).
L’option limitRate du SDK limite un navigateur donné (voir Protection contre les bots).
La périphérie du réseau (CloudFront + AWS WAF) bloque les inondations avant qu’elles n’atteignent l’API.
Le tableau de bord a ses propres limites par utilisateur, p. ex. 10 envois de test par minute en plus de la limite quotidienne d’envois de test du forfait indiquée dans le tableau ci-dessus.