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

# Begränsningar för anropsfrekvens

> Anropsbudgetar för Living Security Public API, svarskontraktet för 429 och hur man gör nya försök med Retry-After.

API:et `/v1` tillämpar två oberoende anropsbudgetar. Ett anrop avvisas
om någon av budgetarna är förbrukad.

| Budget | Gäller för |
| - | - |
| Per API-nyckel | Varje anrop som använder nyckeln, från vilken adress som helst |
| Per klient-IP | Varje anrop från den adressen, oavsett om det är autentiserat eller inte |

Budgeten per nyckel följer med nyckeln oavsett var den används. Budgeten per IP
är den enda budgeten för oautentiserad trafik och ett andra tak för
autentiserad trafik.

<Note>
  Begränsningarna tillämpas före autentiseringen, så anrop med ogiltiga eller
  saknade autentiseringsuppgifter räknas också mot källans budget. De exakta
  numeriska budgetarna konfigureras av operatören och kan ändras; svarskontraktet
  nedan är det stabila gränssnittet att bygga mot.
</Note>

Autentisera med någon av de två formerna av Basic-autentiseringsuppgifter – se
[Snabbstart](/sv/developers/v1/quickstart) (`apikey:secret` eller `secret:`).
Ange `BASE` som organisationens regionala värd – se
[Regioner](/sv/developers/v1/regions).

## Svaret 429

När en budget är förbrukad returnerar API:et `429 Too Many Requests` med en
`Retry-After`-header (i sekunder) och den standardiserade problem-details-kroppen:

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

Svaret anger inte vilken budget som förbrukats. Behandla alla `429` på samma
sätt: vänta och försök sedan igen.

## Hantera 429-svar

<Steps>
  <Step title="Följ Retry-After">
    Vänta minst det antal sekunder som anges i headern `Retry-After` innan du
    försöker igen. Om du försöker igen tidigare förbrukas bara budget på anrop
    som ändå kommer att avvisas.
  </Step>

  <Step title="Öka väntetiden exponentiellt vid upprepade försök">
    Om ett nytt försök avvisas igen ska du öka väntetiden och lägga till slumpmässig jitter
    så att parallella arbetsprocesser inte gör nya försök i takt. Förkorta aldrig serverns `Retry-After` för att passa en lokal
    gräns. Om servern ber dig vänta längre än din budget för nya försök tillåter,
    avbryt och schemalägg arbetet till senare.
  </Step>

  <Step title="Jämna ut anropsfrekvensen">
    Föredra en jämn anropsfrekvens framför stötvisa anropsbursts. För massläsning använder du den största
    sidstorleken (`limit=500`) för att täcka samlingen med färre anrop – se
    [paginering](/sv/developers/v1/pagination). När flera listgenomgångar körs
    parallellt (till exempel Power BI-tabeller) bör du hålla samtidigheten måttlig och följa
    `Retry-After` så att ett tillfälligt 429-svar inte får hela uppdateringen att misslyckas.
  </Step>
</Steps>

Det här exemplet gör nya försök endast för `429`-svar på ett **GET**-anrop, med högst
fem försök och högst 60 sekunders väntetid mellan försöken. Det avbryts
omedelbart vid andra fel. Nätverkstimeouter vidarebefordras till anroparen. Konfigurera
timeouter och budgetar för nya försök efter din arbetsbelastning. `requests` tolkar läs-timeouten
som den längsta tillåtna inaktiva tiden vid mottagning av data, inte som en övergripande tidsgräns.

Läs in `LIVING_SECURITY_API_KEY` från din hemlighetshanterare. Installera `requests`
innan du kör det här exemplet. Anropa `get_with_retry("/organization")` för att använda det.

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

Kopiera inte den här loopen till en skrivoperation. En timeout efter en skrivning kan
betyda att servern hann genomföra den innan anslutningen bröts. Upprepa en skrivning endast
när den operationens referens uttryckligen dokumenterar idempotens, med
samma nyckel och samma nyttolast. Annars bör du stämma av resursens tillstånd innan du försöker igen.

## Rekommenderat uppdateringsschema

Dimensionera uppdateringsintervallet utifrån din nyckelbudget och sidstorlek. En fullständig historisk
inläsning av en stor samling är en engångskostnad; föredra inkrementella tidsfönster för
löpande uppdateringar så att varje körning hålls väl under budgeten. Ange alltid
`limit=500` uttryckligen – standardvärdet 25 multiplicerar antalet anrop.


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