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

# Rate limits

> Aanvraagbudgetten voor de Living Security Public API, het 429-responscontract en hoe u opnieuw probeert met Retry-After.

De `/v1` API hanteert twee onafhankelijke aanvraagbudgetten. Een aanvraag wordt
geweigerd als een van beide budgetten is uitgeput.

| Budget | Van toepassing op |
| - | - |
| Per API-sleutel | Elke aanvraag die deze sleutel gebruikt, vanaf elk adres |
| Per client-IP | Elke aanvraag vanaf dit adres, al dan niet geauthenticeerd |

Het budget per sleutel volgt de sleutel overal waar deze wordt gebruikt. Het
budget per IP is het enige budget voor niet-geauthenticeerd verkeer en een
tweede limiet voor geauthenticeerd verkeer.

<Note>
  Limieten worden afgedwongen vóór de authenticatie, waardoor aanvragen met
  ongeldige of ontbrekende inloggegevens ook meetellen voor het budget van de
  bron. De exacte numerieke budgetten worden door de operator geconfigureerd en
  kunnen wijzigen; het onderstaande responscontract is de stabiele interface
  waarop u kunt bouwen.
</Note>

Authenticeer met een van beide Basic-credentialvormen; zie de
[Quickstart](/nl/developers/v1/quickstart) (`apikey:secret` of `secret:`).
Stel `BASE` in op de regionale host van de organisatie; zie
[Regio's](/nl/developers/v1/regions).

## De 429-respons

Wanneer een budget is uitgeput, retourneert de API `429 Too Many Requests` met een
`Retry-After`-header (in seconden) en de standaard problem-details-body:

```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
}
```

De respons geeft niet aan welk budget is uitgeput. Behandel elke `429`
op dezelfde manier: wacht en probeer het daarna opnieuw.

## 429-responses afhandelen

<Steps>
  <Step title="Houd rekening met Retry-After">
    Wacht minimaal het aantal seconden dat in de `Retry-After`-header staat voordat u
    het opnieuw probeert. Als u eerder opnieuw probeert, verbruikt u alleen
    opnieuw budget voor aanvragen die toch worden geweigerd.
  </Step>

  <Step title="Verleng de wachttijd exponentieel bij herhaling">
    Als een nieuwe poging opnieuw wordt geweigerd, verhoogt u uw backoff en voegt
    u willekeurige jitter toe, zodat parallelle workers niet synchroon opnieuw
    proberen. Verkort nooit de `Retry-After` van de server om binnen een lokale limiet te
    passen. Als de server u vraagt langer te wachten dan uw retrybudget toestaat,
    stopt u en plant u het werk voor later.
  </Step>

  <Step title="Spreid uw aanvraagfrequentie">
    Geef de voorkeur aan een constante aanvraagfrequentie boven pieken. Gebruik
    voor bulkleesacties de maximale paginagrootte (`limit=500`) om de collectie met
    minder aanvragen te doorlopen; zie [paginering](/nl/developers/v1/pagination).
    Wanneer meerdere lijstdoorlopen parallel worden uitgevoerd (bijvoorbeeld
    Power BI-tabellen), houd de gelijktijdigheid dan bescheiden en houd rekening
    met `Retry-After`, zodat een tijdelijke 429 niet de hele verversing laat mislukken.
  </Step>
</Steps>

Dit voorbeeld probeert alleen `429`-responses opnieuw voor een **GET**-aanvraag,
met maximaal vijf pogingen en maximaal 60 seconden wachttijd tussen de
pogingen. Bij andere fouten stopt het direct. Netwerktimeouts worden doorgegeven
aan de aanroeper. Configureer timeouts en retrybudgetten naar uw workload.
`requests` interpreteert de leestimeout als de maximale inactieve tijd tijdens het
ontvangen van gegevens, niet als een algemene deadline.

Laad `LIVING_SECURITY_API_KEY` uit uw secretmanager. Installeer `requests`
voordat u dit voorbeeld uitvoert. Roep `get_with_retry("/organization")` aan om het te gebruiken.

```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)
```

Kopieer deze lus niet rond een schrijfbewerking. Een timeout na een schrijfactie
kan betekenen dat de server deze heeft doorgevoerd voordat de verbinding
verbrak. Herhaal een schrijfbewerking alleen als de referentie van die
bewerking idempotentie expliciet documenteert, en behoud dezelfde sleutel en
payload. Controleer anders eerst de status van de resource voordat u het
opnieuw probeert.

## Aanbevolen verversingsschema

Stem de verversingsfrequentie af op uw sleutelbudget en paginagrootte. Een
volledige historische load van een grote collectie is een eenmalige kostenpost;
geef voor reguliere verversingen de voorkeur aan incrementele vensters, zodat
elke run ruim binnen het budget blijft. Stel `limit=500` altijd expliciet in; de
standaardwaarde van 25 vermenigvuldigt het aantal aanvragen.


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