Przejdź do głównej zawartości

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).

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ń
Free220
Starter520
Pro2020
Business 50k5020
Business 100k5020
Business 200k5020

Żą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.

Żą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.

Żą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.

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 Requests
Retry-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.

  • 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 limitRate w 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.