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

# Ātruma ierobežojumi

> Pieprasījumu limiti Living Security Public API, 429 atbildes līgums un kā atkārtot pieprasījumus, izmantojot Retry-After.

`/v1` API nodrošina divus neatkarīgus pieprasījumu limitus. Pieprasījums tiek noraidīts,
ja ir izsmelts jebkurš no limitiem.

| Limits | Attiecas uz |
| - | - |
| Katrai API atslēgai | Katru pieprasījumu, kurā tiek uzrādīta šī atslēga, neatkarīgi no adreses |
| Katrai klienta IP adresei | Katru pieprasījumu no šīs adreses, neatkarīgi no tā, vai tas ir autentificēts |

Limits katrai atslēgai seko atslēgai visur, kur tā tiek izmantota. Limits katrai IP adresei
ir vienīgais limits neautentificētai datplūsmai un otrs augšējais slieksnis
autentificētai datplūsmai.

<Note>
  Limiti tiek piemēroti pirms autentifikācijas, tāpēc pieprasījumi ar nederīgiem vai
  trūkstošiem akreditācijas datiem arī tiek ieskaitīti avota limitā. Precīzus skaitliskos
  limitus konfigurē operators, un tie var mainīties; tālāk aprakstītais atbildes līgums
  ir stabilā saskarne, uz kuras balstīt izstrādi.
</Note>

Autentificējieties, izmantojot jebkuru no Basic akreditācijas datu formātiem — skatiet
[Quickstart](/lv/developers/v1/quickstart) (`apikey:secret` vai `secret:`).
Iestatiet `BASE` uz organizācijas reģionālo resursdatoru — skatiet
[Regions](/lv/developers/v1/regions).

## 429 atbilde

Kad limits ir izsmelts, API atgriež `429 Too Many Requests` ar
`Retry-After` galveni (sekundēs) un standarta problem-details pamattekstu:

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

Atbildē nav norādīts, kurš limits ir izsmelts. Visas `429` atbildes apstrādājiet
vienādi: uzgaidiet un atkārtojiet pieprasījumu.

## 429 atbilžu apstrāde

<Steps>
  <Step title="Ņemiet vērā Retry-After">
    Pirms atkārtošanas uzgaidiet vismaz tik sekunžu, cik norādīts `Retry-After` galvenē.
    Atkārtojot pieprasījumu ātrāk, tiek tikai velti tērēts limits pieprasījumiem,
    kas tiks noraidīti.
  </Step>

  <Step title="Atkārtojumu gadījumā izmantojiet eksponenciālo atkāpšanos">
    Ja atkārtotais pieprasījums tiek noraidīts vēlreiz, palieliniet atkāpšanās laiku un pievienojiet nejaušu novirzi (jitter),
    lai paralēlie darbinieki neatkārtotu pieprasījumus vienlaikus. Nekad nesaīsiniet servera norādīto `Retry-After`, lai pielāgotos lokālajam
    ierobežojumam. Ja serveris prasa gaidīt ilgāk, nekā pieļauj jūsu atkārtojumu limits,
    apturiet darbu un ieplānojiet to vēlākam laikam.
  </Step>

  <Step title="Izlīdziniet pieprasījumu ātrumu">
    Dodiet priekšroku vienmērīgam pieprasījumu ātrumam, nevis pārsprāgumiem. Lielapjoma nolasīšanai izmantojiet maksimālo
    lapas izmēru (`limit=500`), lai apstrādātu kolekciju ar mazāk pieprasījumiem — skatiet
    [pagination](/lv/developers/v1/pagination). Ja vairāki sarakstu apgūšanas procesi darbojas
    paralēli (piemēram, Power BI tabulas), saglabājiet mērenu paralēlismu un ņemiet vērā
    `Retry-After`, lai īslaicīga 429 atbilde neizraisītu visa atsvaidzināšanas procesa kļūmi.
  </Step>
</Steps>

Šis piemērs atkārto tikai `429` atbildes **GET** pieprasījumam, ar ne vairāk kā
pieciem mēģinājumiem un ne vairāk kā 60 sekunžu gaidīšanu starp mēģinājumiem. Citu kļūdu gadījumā tas
apstājas nekavējoties. Tīkla noildzes tiek nodotas izsaucējam. Konfigurējiet
noildzes un atkārtojumu limitus atbilstoši savai darba slodzei. `requests` interpretē lasīšanas
noildzi kā maksimālo dīkstāves laiku datu saņemšanas laikā, nevis kā kopējo termiņu.

Ielādējiet `LIVING_SECURITY_API_KEY` no sava noslēpumu pārvaldnieka. Pirms šī piemēra
palaišanas instalējiet `requests`. Lai to izmantotu, izsauciet `get_with_retry("/organization")`.

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

Nekopējiet šo ciklu ap rakstīšanas operāciju. Noildze pēc rakstīšanas var nozīmēt,
ka serveris to ir apstiprinājis, pirms savienojums pārtrūka. Atkārtojiet rakstīšanu tikai tad,
ja attiecīgās operācijas atsaucē ir skaidri dokumentēta idempotence, saglabājot to pašu
atslēgu un datu kopu. Pretējā gadījumā pirms atkārtošanas saskaņojiet resursa stāvokli.

## Ieteicamais atsvaidzināšanas grafiks

Pielāgojiet atsvaidzināšanas biežumu savam atslēgas limitam un lapas izmēram. Lielas kolekcijas pilnā
vēsturiskā ielāde ir vienreizējas izmaksas; ikdienas atsvaidzināšanai dodiet priekšroku inkrementāliem logiem,
lai katra izpilde paliktu krietni zem limita. Vienmēr skaidri iestatiet
`limit=500` — noklusējuma vērtība 25 palielina pieprasījumu skaitu.


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