Rate limit

Frontmail limita la velocità con cui si possono inviare richieste, per proteggere i tuoi crediti dagli abusi e i tuoi provider dai picchi improvvisi. I limiti vengono conteggiati in finestre temporali fisse (di un secondo per i limiti del piano e della chiave, di una durata a tua scelta per il limite per IP).

Per organizzazione (piano)

Tutte le richieste di un’organizzazione insieme – con chiave pubblica e privata – condividono un limite che dipende dal piano:

Piano	Richieste al secondo (per organizzazione e per chiave)	Invii di prova / giorno
Free	2	20
Starter	5	20
Pro	20	20
Business 50k	50	20
Business 100k	50	20
Business 200k	50	20

Una richiesta batch conta come una sola richiesta per il rate limit, ma ogni messaggio al suo interno consuma un credito – per gli invii massivi dai server usa /v1/send-batch.

Per indirizzo IP

Le richieste con chiave pubblica sono limitate anche per IP del client, così un singolo visitatore o bot non può esaurire il limite della tua organizzazione. Il valore predefinito è 10 richieste ogni 60 secondi per IP. Proprietari e admin lo modificano in Sicurezza → Rate limit per IP con due campi, Richieste e Ogni (secondi) – la pagina lo riassume come Al massimo N richieste ogni M secondi da un singolo indirizzo IP. Le richieste con chiave privata non sono limitate per IP. I client IPv6 vengono conteggiati per rete /64 (il blocco che di solito riceve una singola connessione domestica o un server), quindi cambiare indirizzo al suo interno non aiuta un bot. L’indirizzo del client viene preso dalla CDN di Frontmail; le richieste che provano ad aggirarla vengono rifiutate.

Per chiave

Le richieste vengono conteggiate anche per chiave, con lo stesso limite al secondo del tuo piano.

Per le richieste con chiave pubblica, i limiti del piano e della chiave (e il rilevamento delle anomalie) conteggiano solo le richieste che hanno superato la ricerca del modello e – quando il modello lo richiede – il controllo CAPTCHA. Una raffica di richieste non valide (template_id sconosciuto, token Turnstile mancante) viene rifiutata senza consumare il limite di cui hanno bisogno i tuoi visitatori reali; a queste richieste si applica solo una generosa protezione anti-flood (almeno 50 richieste al secondo per organizzazione). Dai a ogni server o job la sua chiave privata: se uno di loro si comporta male, lo vedi in Sicurezza → Chiavi private (Ultimo utilizzo) e puoi revocare solo quella chiave.

Quando raggiungi un limite

L’API risponde con 429 rate_limited e un header Retry-After in secondi. Gli SDK attendono e riprovano automaticamente quando Retry-After è al massimo di 60 secondi. Le richieste respinte per rate limit non consumano crediti.

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

Anche il tuo provider email ha i propri limiti (per esempio Amazon SES in modalità sandbox consente 1 messaggio al secondo). Il mittente li rispetta distribuendo gli invii nel tempo: i messaggi vengono ritardati, ma le tue richieste non vengono rifiutate.

Altre protezioni

Il rilevamento delle anomalie rallenta i picchi improvvisi e insoliti di richieste con chiave pubblica a una richiesta ogni due secondi.
I caricamenti prefirmati con la chiave pubblica (POST /v1/uploads) hanno un budget giornaliero di byte per organizzazione (200 × il limite degli allegati del tuo piano).
L’opzione limitRate dell’SDK limita un singolo browser (vedi Protezione dai bot).
L’edge (CloudFront + AWS WAF) blocca le raffiche prima che raggiungano l’API.
La dashboard ha i propri limiti per utente, ad es. 10 invii di prova al minuto oltre al limite giornaliero di invii di prova del piano riportato nella tabella qui sopra.