W automatyzacjach chronią usługę przed przeciążeniem, ale bez kolejki, kontrolowanej współbieżności i bezpiecznych ponowień mogą przerwać import leadów, synchronizację CRM lub follow-up po kampanii.
Spis treści
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.
Najczęstsze pytania
Co oznacza błąd 429 Too Many Requests?
Błąd 429 oznacza, że usługa otrzymała zbyt wiele żądań w przyjętym przez nią czasie. Nie zakładaj jednego powodu ani jednego czasu oczekiwania. Sprawdź dokumentację i nagłówki odpowiedzi, zwłaszcza Retry-After, ogranicz tempo workflowu i ponów wyłącznie bezpieczny krok.
Czy rate limiting oznacza, że moja automatyzacja jest źle zbudowana?
Nie zawsze. Limity są normalną częścią korzystania z API, także w dobrze zbudowanym systemie. Problemem jest brak obsługi limitu: równoległe masowe żądania, brak kolejki, ponawianie bez przerwy albo brak logu rekordów, które nie przeszły. Projekt powinien zakładać, że limit kiedyś zostanie osiągnięty.
