Rate Limiting (limitowanie zapytań)

Rate Limiting to mechanizm ochronny, który ogranicza liczbę żądań API w danym oknie czasowym, aby zapewnić uczciwe korzystanie i stabilność systemu. Po przekroczeniu limitu otrzymujesz odpowiedź HTTP 429 z nagłówkiem Retry-After.

Czym jest Rate Limiting?

Rate Limiting (limitowanie zapytań) kontroluje, ile żądań do API klient może wysłać w określonym czasie – np. 100 żądań na minutę lub 10 000 wiadomości dziennie. Limity te chronią infrastrukturę API przed przeciążeniem i zapewniają wszystkim klientom równy dostęp. Bez limitowania zapytań jeden wadliwy bot mógłby wysyłać tysiące żądań na sekundę i spowolnić usługę dla wszystkich pozostałych.

Technicznie limitowanie zapytań realizuje się najczęściej za pomocą algorytmów Token Bucket lub Sliding Window. Każdy klucz API ma "budżet" żądań, który stale się uzupełnia. Gdy wysyłasz żądanie, zużywasz jeden token. Gdy wszystkie tokeny się wyczerpią, musisz poczekać, aż pojawią się nowe. SendSeven stosuje uczciwy, przejrzysty system z jasnymi komunikatami o błędach i wskazówkami dotyczącymi ponowienia.

Dlaczego istnieją limity zapytań?

Stabilność systemu: API współdzielą zasoby (procesor, baza danych, sieć). Pojedynczy "złośliwy" klient mógłby bez limitów sparaliżować cały system – Rate Limiting zapobiega takim scenariuszom typu Denial of Service.

Uczciwe korzystanie: wszyscy klienci powinni czerpać korzyści w równym stopniu. Jeśli jeden klient zużyje 90% przepustowości, inni na tym tracą. Limity zapytań dbają o sprawiedliwość.

Kontrola kosztów: przypadkowe nieskończone pętle w kodzie mogłyby bez limitów wysłać miliony żądań – i wygenerować odpowiadające im koszty. Rate Limiting działa jak hamulec awaryjny.

Ochrona przed nadużyciami: spamerzy i atakujący często próbują zalać API. Limity zapytań sprawiają, że takie ataki stają się nieopłacalne i łatwiejsze do wykrycia.

Obsługa odpowiedzi HTTP 429

Po przekroczeniu limitu zapytań API odpowiada kodem HTTP 429 (Too Many Requests). Nagłówek odpowiedzi zawiera ważne informacje:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1676543210

Retry-After: ile sekund musisz odczekać przed kolejnym dozwolonym żądaniem.

X-RateLimit-Limit: Twój całkowity limit (np. 100 żądań/minutę).

X-RateLimit-Remaining: ile żądań jest jeszcze dostępnych (tutaj: 0).

X-RateLimit-Reset: znacznik czasu Unix wskazujący, kiedy limit zostanie zresetowany.

Profesjonalne aplikacje implementują Exponential Backoff: po błędzie 429 nie czekasz po prostu stałe 60 sekund, lecz podwajasz czas oczekiwania przy każdym kolejnym błędzie (1 s, 2 s, 4 s, 8 s, ...). Zapobiega to problemom typu "Thundering Herd", w których tysiące klientów jednocześnie ponawiają żądania i ponownie przeciążają system.

Limity zapytań w SendSeven

SendSeven liczy limity zapytań na przestrzeń roboczą, a nie na klucz API; endpointy logowania i uwierzytelniania liczone są na adres IP. Każdy limit obowiązuje w przesuwnym oknie 60 sekund, a Twoja integracja dzieli ten budżet z panelem. Limity są takie same w każdym planie. Każda odpowiedź zawiera nagłówki X-RateLimit-Limit, X-RateLimit-Remaining i X-RateLimit-Reset, więc Twoja aplikacja zawsze wie, na czym stoi. Po przekroczeniu limitu API zwraca odpowiedź 429 z nagłówkiem Retry-After, który podaje, ile sekund należy odczekać.

Do wysyłki masowej zamiast pojedynczych wywołań API polecamy wbudowaną funkcję Reach (Kampanie) SendSeven. Kampanie są przetwarzane po stronie serwera: szybkość wysyłki i wielkość partii ustawiasz w kampanii, a w WhatsAppie możesz rozłożyć dużą wysyłkę na kilka dni, aby chronić nowy numer. Nie musisz przy tym samodzielnie zarządzać limitami.

Aktualne wartości znajdziesz w dokumentacji API na docs.sendseven.com. Najlepsza praktyka: obserwuj X-RateLimit-Remaining, zwalniaj, zanim licznik spadnie do zera, i kolejkuj żądania po stronie klienta (np. Bull dla Node.js, Celery dla Pythona), aby błąd 429 nigdy nie dotarł do Twoich użytkowników.