Skip to main content
Interfejs API /v1 egzekwuje dwa niezależne budżety żądań. Żądanie jest odrzucane, jeśli którykolwiek z budżetów został wyczerpany. Budżet przypisany do klucza obowiązuje wszędzie tam, gdzie klucz jest używany. Budżet przypisany do adresu IP jest jedynym budżetem dla ruchu nieuwierzytelnionego oraz drugim limitem dla ruchu uwierzytelnionego.
Limity są egzekwowane przed uwierzytelnieniem, więc żądania z nieprawidłowymi lub brakującymi danymi uwierzytelniającymi również wliczają się do budżetu źródła. Dokładne wartości liczbowe budżetów są konfigurowane przez operatora i mogą ulec zmianie; przedstawiony poniżej kontrakt odpowiedzi jest stabilnym interfejsem, na którym należy oprzeć implementację.
Uwierzytelnij się przy użyciu dowolnej z dwóch postaci danych uwierzytelniających Basic — zobacz Szybki start (apikey:secret lub secret:). Ustaw BASE na regionalny host organizacji — zobacz Regiony.

Odpowiedź 429

Gdy budżet zostanie wyczerpany, interfejs API zwraca 429 Too Many Requests wraz z nagłówkiem Retry-After (w sekundach) oraz standardową treścią problem-details:
429 Too Many Requests
Odpowiedź nie wskazuje, który budżet został wyczerpany. Każdą odpowiedź 429 należy traktować tak samo: poczekać, a następnie ponowić żądanie.

Obsługa odpowiedzi 429

1

Przestrzegaj nagłówka Retry-After

Przed ponowieniem żądania odczekaj co najmniej liczbę sekund podaną w nagłówku Retry-After. Wcześniejsze ponowienie jedynie zużywa budżet na żądania, które i tak zostaną odrzucone.
2

Stosuj wykładniczy backoff przy kolejnych odmowach

Jeśli ponowione żądanie zostanie ponownie odrzucone, wydłuż czas oczekiwania i dodaj losowy jitter, aby równoległe procesy robocze nie ponawiały żądań w tym samym momencie. Nigdy nie skracaj wartości Retry-After serwera w celu dopasowania do lokalnego limitu. Jeśli serwer wymaga dłuższego oczekiwania, niż pozwala na to Twój budżet ponowień, zatrzymaj się i zaplanuj wykonanie zadania na później.
3

Wygładź tempo wysyłania żądań

Preferuj stałe tempo żądań zamiast gwałtownych serii. Przy zbiorczym odczycie danych użyj maksymalnego rozmiaru strony (limit=500), aby objąć kolekcję mniejszą liczbą żądań — zobacz paginację. Gdy równolegle przebiega kilka przejść po listach (na przykład tabele Power BI), utrzymuj umiarkowaną współbieżność i przestrzegaj Retry-After, aby tymczasowa odpowiedź 429 nie powodowała niepowodzenia całego odświeżania.
Ten przykład ponawia wyłącznie odpowiedzi 429 dla żądania GET, maksymalnie pięć prób i z czasem oczekiwania między próbami nie dłuższym niż 60 sekund. W przypadku innych błędów natychmiast się zatrzymuje. Przekroczenia czasu sieciowego są przekazywane do wywołującego. Skonfiguruj limity czasu i budżety ponowień odpowiednio do swojego obciążenia. requests interpretuje limit czasu odczytu jako maksymalny czas bezczynności podczas odbierania danych, a nie jako całkowity termin. Wczytaj LIVING_SECURITY_API_KEY z menedżera sekretów. Zainstaluj requests przed uruchomieniem tego przykładu. Wywołaj get_with_retry("/organization"), aby go użyć.
Python
Nie kopiuj tej pętli do operacji zapisu. Przekroczenie czasu po zapisie może oznaczać, że serwer zatwierdził zapis, zanim połączenie zostało przerwane. Powtarzaj zapis wyłącznie wtedy, gdy dokumentacja danej operacji jawnie opisuje idempotentność, zachowując ten sam klucz i ten sam ładunek. W przeciwnym razie przed ponowną próbą uzgodnij stan zasobu.

Zalecany harmonogram odświeżania

Dobierz częstotliwość odświeżania do budżetu klucza i rozmiaru strony. Pełne załadowanie danych historycznych dużej kolekcji to koszt jednorazowy; w odświeżaniach w stanie ustalonym preferuj okna przyrostowe, aby każde uruchomienie mieściło się znacznie poniżej budżetu. Zawsze ustawiaj limit=500 jawnie — wartość domyślna 25 zwielokrotnia liczbę żądań.