> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limity szybkości żądań

> Budżety żądań dla Living Security Public API, kontrakt odpowiedzi 429 oraz sposób ponawiania żądań z użyciem nagłówka Retry-After.

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 | Dotyczy |
| - | - |
| Na klucz API | Każdego żądania przekazującego dany klucz, z dowolnego adresu |
| Na adres IP klienta | Każdego żądania z tego adresu, uwierzytelnionego lub nie |

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.

<Note>
  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ę.
</Note>

Uwierzytelnij się przy użyciu dowolnej z dwóch postaci danych uwierzytelniających Basic — zobacz
[Szybki start](/pl/developers/v1/quickstart) (`apikey:secret` lub `secret:`).
Ustaw `BASE` na regionalny host organizacji — zobacz
[Regiony](/pl/developers/v1/regions).

## 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:

```json 429 Too Many Requests theme={null}
{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/rate_limited",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Rate limit exceeded. Retry after the Retry-After interval.",
  "code": "rate_limited",
  "request_id": "req_...",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/rate_limited",
  "retryable": true
}
```

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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ę](/pl/developers/v1/pagination). 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.
  </Step>
</Steps>

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 Python theme={null}
import os
import random
import time
import requests

# US: BASE = "https://api.us-east-1.livingsecurity.ai/v1"
BASE = "https://api.eu-west-1.livingsecurity.ai/v1"
AUTH = ("apikey", os.environ["LIVING_SECURITY_API_KEY"])

def get_with_retry(path, params=None, max_attempts=5):
    if not 1 <= max_attempts <= 5:
        raise ValueError("max_attempts must be between 1 and 5")
    for attempt in range(max_attempts):
        response = requests.get(
            f"{BASE}{path}", auth=AUTH, params=params,
            headers={"Living-Security-Version": "2026-07-01"},
            timeout=(5, 30), allow_redirects=False,
        )
        if response.status_code != 429:
            response.raise_for_status()
            if not 200 <= response.status_code < 300:
                raise RuntimeError("Unexpected redirect; check your regional API URL")
            return response

        # The API returns Retry-After as a whole number of seconds.
        raw_wait = response.headers.get("Retry-After", "")
        request_id = response.headers.get("Request-Id", "unknown")
        response.close()
        if attempt == max_attempts - 1:
            raise RuntimeError(f"Retry budget exhausted; request_id={request_id}")
        if not raw_wait.isascii() or not raw_wait.isdigit() or len(raw_wait) > 6:
            raise RuntimeError(f"Invalid Retry-After; request_id={request_id}")

        wait = max(int(raw_wait), min(2 ** attempt, 30))
        delay = wait + random.uniform(0, 1)
        if delay > 60:
            raise RuntimeError(f"Retry-After exceeds wait budget; request_id={request_id}")
        time.sleep(delay)
```

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.