Rate limity
Frontmail ogranicza tempo wysyłania żądań, żeby chronić twoje kredyty przed nadużyciami, a twoich dostawców przed nagłymi skokami ruchu. Limity liczone są w stałych oknach czasowych (jednosekundowych dla limitów planu i klucza, a dla limitu na IP – w oknie, które sam ustawiasz).
Na organizację (według planu)
Dział zatytułowany „Na organizację (według planu)”Wszystkie żądania organizacji łącznie – z kluczem publicznym i prywatnym – dzielą limit zależny od planu:
| Plan | Żądania na sekundę (na organizację i na klucz) | Wysyłki testowe / dzień |
|---|---|---|
| Free | 2 | 20 |
| Starter | 5 | 20 |
| Pro | 20 | 20 |
| Business 50k | 50 | 20 |
| Business 100k | 50 | 20 |
| Business 200k | 50 | 20 |
Żądanie zbiorcze liczy się do rate limitu jako jedno żądanie, ale każda wiadomość w nim zużywa
kredyt – do wysyłki masowej z serwerów używaj /v1/send-batch.
Na adres IP
Dział zatytułowany „Na adres IP”Żądania z kluczem publicznym są dodatkowo ograniczone według adresu IP klienta, żeby pojedynczy
odwiedzający albo bot nie mógł wyczerpać limitu całej organizacji. Domyślnie to 10 żądań na
60 sekund na adres IP. Właściciel i administratorzy zmieniają to w Bezpieczeństwo → Limit żądań
na IP za pomocą dwóch pól, Żądania i Na (sekund) – strona podsumowuje to zdaniem
Maksymalnie N żądań na M s z jednego adresu IP. Żądania z kluczem prywatnym nie są ograniczane
według IP. Klientów IPv6 liczymy według sieci /64 (bloku, który zwykle dostaje jedno łącze domowe
albo serwerowe), więc zmienianie adresów w jego obrębie nic botowi nie da. Adres klienta bierzemy
z CDN Frontmail; żądania, które próbują go ominąć, są odrzucane.
Na klucz
Dział zatytułowany „Na klucz”Żądania są liczone także osobno dla każdego klucza, z takim samym limitem na sekundę jak w planie.
W przypadku żądań z kluczem publicznym do limitów planu i klucza (oraz do
wykrywania anomalii) wliczają się tylko żądania, które przeszły
wyszukanie szablonu i – jeśli szablon tego wymaga – weryfikację CAPTCHA. Zalew nieprawidłowych żądań
(nieznany template_id, brak tokenu Turnstile) odrzucamy bez zużywania limitu, którego potrzebują
twoi prawdziwi odwiedzający; dla takich żądań obowiązuje tylko hojne zabezpieczenie przed zalewem
(co najmniej 50 żądań na sekundę na organizację). Daj każdemu serwerowi lub zadaniu własny klucz
prywatny: jeśli któryś zacznie się dziwnie zachowywać, zobaczysz to w Bezpieczeństwo → Klucze
prywatne (Ostatnio użyty) i unieważnisz tylko ten jeden klucz.
Gdy trafisz na limit
Dział zatytułowany „Gdy trafisz na limit”API odpowiada 429 rate_limited z nagłówkiem Retry-After
w sekundach. SDK automatycznie czekają i ponawiają żądanie, gdy Retry-After wynosi najwyżej
60 sekund. Żądania odrzucone przez rate limit nie zużywają kredytów.
HTTP/1.1 429 Too Many RequestsRetry-After: 2
{ "error": { "code": "rate_limited", "message": "Too many requests.", "docs_url": "https://docs.frontmail.dev/reference/errors/#rate-limited" } }Twój dostawca e-maili też ma własne limity (na przykład Amazon SES w trybie sandbox pozwala na 1 wiadomość na sekundę). Moduł wysyłki ich przestrzega, rozkładając doręczanie w czasie – wiadomości są wtedy opóźnione, ale twoje żądania nie są odrzucane.
Inne zabezpieczenia
Dział zatytułowany „Inne zabezpieczenia”- Wykrywanie anomalii spowalnia nagłe, nietypowe skoki żądań z kluczem publicznym do jednego żądania co dwie sekundy.
- Przesyłanie plików przez presigned URL z kluczem publicznym (
POST /v1/uploads) ma dzienny limit objętości na organizację (200 × limit załączników twojego planu). - Opcja
limitRatew SDK ogranicza pojedynczą przeglądarkę (zobacz Ochrona przed botami). - Warstwa brzegowa (CloudFront + AWS WAF) blokuje zalew żądań, zanim dotrze do API.
- Panel ma własne limity na użytkownika, np. 10 wysyłek testowych na minutę, niezależnie od dziennego limitu wysyłek testowych z tabeli powyżej.