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

# Sebességkorlátok

> A Living Security Public API kéréskeretei, a 429-es válasz szerződése, és az újrapróbálkozás a Retry-After fejléc alapján.

A(z) `/v1` API két egymástól független kéréskeretet alkalmaz. A kérés elutasításra
kerül, ha bármelyik keret kimerült.

| Keret | Hatókör |
| - | - |
| API-kulcsonként | Minden kérés, amely az adott kulcsot használja, bármely címről |
| Kliens IP-címenként | Minden kérés az adott címről, hitelesítve vagy anélkül |

A kulcsonkénti keret követi a kulcsot, bárhol is használják. Az IP-címenkénti keret
az egyetlen keret a nem hitelesített forgalomra, a hitelesített forgalomra pedig
egy második felső korlát.

<Note>
  A korlátokat a hitelesítés előtt érvényesíti a rendszer, ezért az érvénytelen vagy
  hiányzó hitelesítő adatokkal küldött kérések is a forrás keretébe számítanak. A pontos
  számszerű keretek üzemeltetői beállítástól függnek, és változhatnak; az alábbi
  válaszszerződés az a stabil felület, amelyre építeni érdemes.
</Note>

A hitelesítéshez használja a Basic hitelesítő adatok bármelyik formáját – lásd:
[Gyorsindítás](/hu/developers/v1/quickstart) (`apikey:secret` vagy `secret:`).
Állítsa a `BASE` értékét a szervezet regionális hosztjára – lásd:
[Régiók](/hu/developers/v1/regions).

## A 429-es válasz

Ha egy keret kimerül, az API `429 Too Many Requests` választ ad vissza egy
`Retry-After` fejléccel (másodpercben) és a szabványos problem-details törzzsel:

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

A válasz nem jelzi, hogy melyik keret merült ki. Minden `429` választ
kezeljen ugyanúgy: várjon, majd próbálkozzon újra.

## A 429-es válaszok kezelése

<Steps>
  <Step title="A Retry-After fejléc betartása">
    Az újrapróbálkozás előtt várjon legalább a `Retry-After` fejlécben megadott
    számú másodpercet. A korábbi újrapróbálkozás csak olyan kérésekkel
    emészti fel újra a keretet, amelyeket a rendszer úgyis elutasít.
  </Step>

  <Step title="Exponenciális visszalépés ismétlődő hibáknál">
    Ha az újrapróbálkozást ismét elutasítják, növelje a várakozási időt, és adjon
    hozzá véletlenszerű jittert, hogy a párhuzamos munkafolyamatok ne egyszerre
    próbálkozzanak újra. A kiszolgáló `Retry-After` értékét soha ne rövidítse le egy helyi
    korláthoz igazodva. Ha a kiszolgáló hosszabb várakozást kér, mint amennyit az
    újrapróbálkozási kerete megenged, hagyja abba, és ütemezze a feladatot későbbre.
  </Step>

  <Step title="A kérések sebességének egyenletesen tartása">
    Részesítse előnyben az egyenletes kérési sebességet a löketszerű terheléssel
    szemben. Tömeges olvasásnál használja a maximális lapméretet (`limit=500`), hogy a
    gyűjteményt kevesebb kéréssel fedje le – lásd:
    [lapozás](/hu/developers/v1/pagination). Ha több listabejárás fut párhuzamosan
    (például Power BI táblák), tartsa mérsékelten a párhuzamosságot, és vegye
    figyelembe a `Retry-After` fejlécet, hogy egy átmeneti 429-es válasz ne akassza meg a
    teljes frissítést.
  </Step>
</Steps>

Ez a példa csak a `429` válaszok esetén próbálkozik újra **GET** kérésnél,
legfeljebb öt kísérlettel és a kísérletek között legfeljebb 60 másodperc
várakozással. Más hibáknál azonnal leáll. A hálózati időtúllépések eljutnak a
hívóhoz. Az időtúllépéseket és az újrapróbálkozási kereteket a saját
munkaterheléséhez igazítva állítsa be. A(z) `requests` az olvasási időtúllépést az
adatfogadás közbeni maximális tétlenségi időként értelmezi, nem pedig teljes
határidőként.

Töltse be a `LIVING_SECURITY_API_KEY` értékét a titokkezelőjéből. A példa futtatása előtt telepítse a
következőt: `requests`. A használatához hívja meg a következőt: `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)
```

Ne másolja ezt a ciklust írási művelet köré. Az írás utáni időtúllépés azt is
jelentheti, hogy a kiszolgáló még a kapcsolat megszakadása előtt véglegesítette
a műveletet. Írást csak akkor ismételjen meg, ha az adott művelet referenciája
kifejezetten dokumentálja az idempotenciát, és ugyanazt a kulcsot és adattartalmat
használja. Ellenkező esetben az újrapróbálkozás előtt egyeztesse az erőforrás állapotát.

## Ajánlott frissítési ütemezés

A frissítési gyakoriságot a kulcs kerete és a lapméret alapján méretezze. Egy nagy
gyűjtemény teljes előzményeinek betöltése egyszeri költség; az állandósult
állapotú frissítésekhez részesítse előnyben az inkrementális időablakokat, hogy
minden futás jóval a keret alatt maradjon. A következőt mindig állítsa be
explicit módon: `limit=500` – az alapértelmezett 25 megsokszorozza a kérések számát.


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