Limity szybkości API (rate limiting)

Limity szybkości API, nazywane rate limitingiem, to zasady określające, ile żądań można wysłać do danego interfejsu w określonym czasie. Chronią usługę przed przeciążeniem i nadużyciami, a dla osoby budującej automatyzacje oznaczają prostą rzecz: workflow może działać poprawnie na kilku rekordach, lecz wyłożyć się przy imporcie setek kontaktów lub nagłym ruchu z kampanii.

Co oznacza błąd 429?

Najczęstszym sygnałem przekroczenia limitu jest odpowiedź HTTP 429 Too Many Requests. Standard HTTP mówi, że serwer może podać, jak długo czekać przed kolejną próbą, na przykład w nagłówku Retry-After. Konkretna usługa sama ustala jednak, co liczy: żądania na sekundę, na minutę, na użytkownika, klucz API, endpoint albo liczbę równoległych połączeń. Dlatego nie istnieje jeden uniwersalny limit dla „API”.

Dlaczego to ma znaczenie w systemie AI i sprzedaży wiedzy?

W systemie eksperta pojedynczy formularz może uruchomić kilka kroków: zapis kontaktu, wzbogacenie danych, generowanie podsumowania przez model, aktualizację CRM i wysłanie maila. Gdy do formularza wpada większa grupa osób albo automatyzacja przetwarza archiwum, kroki mogą uderzyć w ten sam limit. Efekt bywa zdradliwy: część rekordów przechodzi, część dostaje 429, a klient nie widzi obiecanego follow-upu. Limit nie jest błędem „AI”, tylko ograniczeniem po stronie integracji, które trzeba uwzględnić w projekcie procesu.

Jak projektować automatyzację odporną na limity?

Najpierw przeczytaj dokumentację każdego krytycznego API i sprawdź, czy limit dotyczy całego konta, konkretnego endpointu czy równoległych zadań. Następnie ogranicz współbieżność i przetwarzaj większe listy w małych porcjach. Przy odpowiedzi 429 respektuj Retry-After, jeśli dostawca go zwraca. W innym przypadku stosuj ograniczoną liczbę ponowień z rosnącym odstępem, czyli exponential backoff, oraz losowym odchyleniem czasu. Nie odpalaj tego samego żądania bez końca. Po określonej liczbie prób zadanie powinno trafić do kolejki błędów wraz z identyfikatorem rekordu i odpowiedzią API.

Praktyczny przykład: kampania i follow-up

Załóżmy, że po live do bazy trafia 300 zapisów. Zamiast wysyłać równolegle 300 aktualizacji do CRM i 300 osobnych zapytań do modelu, workflow dzieli dane na porcje, na przykład po 10 rekordów, a pomiędzy porcjami robi przerwę zgodną z limitem usług. Dla każdego kroku zapisuje status. Jeśli CRM zwróci 429, proces czeka tyle, ile wskazuje dokumentacja lub nagłówek, ponawia tylko ten rekord i nie wysyła drugi raz wiadomości do osoby, której etap już się udał. Do tego potrzebna jest idempotencja w automatyzacji, aby retry nie tworzyło duplikatów.

Czego nie robić?

Nie zgaduj limitów na podstawie krótkiego testu. Nie traktuj 429 jak błędu, który naprawi „uruchom ponownie”. Nie zwiększaj bezmyślnie liczby równoległych gałęzi w n8n tylko po to, by skrócić import. I nie mieszaj limitu szybkości z limitem kosztów modelu lub z limitem kontekstu. To trzy różne ograniczenia. Dobrze zbudowany system ma kolejkę, obserwowalny log błędów, bezpieczne ponowienia i wolniejszą ścieżkę awaryjną dla ważnych danych.

Jak sprawdzić to przed publikacją automatyzacji?

Zrób test na małej partii, potem na kontrolowanej większej partii, i obserwuj odpowiedzi oraz czas wykonania. Zapisz w źródle prawdy procesu: jaki jest limit, jaki endpoint go wykorzystuje, ile prób wykonujesz, gdzie trafia błąd i kto go sprawdza. Przy usługach takich jak Google Sheets, GitHub czy Stripe limity są opisane w oficjalnej dokumentacji i mogą się zmieniać. Wróć do niej, zanim podniesiesz skalę kampanii lub importu.