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

# Limite de rată

> Bugetele de solicitări pentru API-ul public Living Security, contractul răspunsului 429 și modul de reîncercare cu Retry-After.

API-ul `/v1` aplică două bugete de solicitări independente. O solicitare este refuzată
dacă oricare dintre bugete este epuizat.

| Buget | Se aplică pentru |
| - | - |
| Per cheie API | Fiecare solicitare care prezintă acea cheie, de la orice adresă |
| Per adresă IP a clientului | Fiecare solicitare de la acea adresă, autentificată sau nu |

Bugetul per cheie urmărește cheia oriunde este utilizată. Bugetul per IP este
singurul buget pentru traficul neautentificat și o a doua limită pentru traficul
autentificat.

<Note>
  Limitele sunt aplicate înainte de autentificare, astfel că solicitările cu
  credențiale nevalide sau lipsă se contorizează, de asemenea, în bugetul sursei. Valorile numerice exacte ale
  bugetelor sunt configurate de operator și pot fi modificate; contractul
  răspunsului de mai jos este interfața stabilă pe care trebuie să vă bazați.
</Note>

Autentificați-vă cu oricare dintre formele de credențiale Basic — consultați
[Ghid de pornire rapidă](/ro/developers/v1/quickstart) (`apikey:secret` sau `secret:`).
Setați `BASE` la gazda regională a organizației — consultați
[Regiuni](/ro/developers/v1/regions).

## Răspunsul 429

Când un buget este epuizat, API-ul returnează `429 Too Many Requests` cu un
antet `Retry-After` (în secunde) și corpul standard 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
}
```

Răspunsul nu precizează care buget a fost epuizat. Tratați fiecare `429`
în același mod: așteptați, apoi reîncercați.

## Gestionarea răspunsurilor 429

<Steps>
  <Step title="Respectați Retry-After">
    Așteptați cel puțin numărul de secunde din antetul `Retry-After` înainte de
    a reîncerca. O reîncercare mai devreme consumă din nou din buget pentru solicitări care vor fi
    refuzate.
  </Step>

  <Step title="Măriți exponențial intervalul de așteptare la repetări">
    Dacă o reîncercare este refuzată din nou, măriți intervalul de așteptare și adăugați un jitter aleatoriu
    astfel încât procesele paralele să nu reîncerce sincronizat. Nu scurtați niciodată valoarea `Retry-After` a serverului pentru a respecta o
    limită locală. Dacă serverul vă cere să așteptați mai mult decât permite bugetul dvs. de reîncercări,
    opriți-vă și programați lucrarea pentru mai târziu.
  </Step>

  <Step title="Uniformizați rata solicitărilor">
    Preferați o rată constantă a solicitărilor în locul vârfurilor. Pentru citiri în masă, utilizați dimensiunea maximă
    a paginii (`limit=500`) pentru a acoperi colecția cu mai puține solicitări — consultați
    [paginare](/ro/developers/v1/pagination). Când mai multe parcurgeri de liste rulează în
    paralel (de exemplu, tabele Power BI), păstrați un nivel moderat de concurență și respectați
    `Retry-After`, astfel încât un 429 temporar să nu ducă la eșecul întregii reîmprospătări.
  </Step>
</Steps>

Acest exemplu reîncearcă doar răspunsurile `429` pentru o solicitare **GET**, cu cel mult
cinci încercări și cel mult 60 de secunde de așteptare între încercări. Se oprește
imediat la alte erori. Expirările de timp de rețea sunt propagate către apelant. Configurați
expirările de timp și bugetele de reîncercări în funcție de volumul dvs. de lucru. `requests` interpretează timpul limită
de citire ca timpul maxim de inactivitate la primirea datelor, nu ca termen limită total.

Încărcați `LIVING_SECURITY_API_KEY` din managerul dvs. de secrete. Instalați `requests`
înainte de a rula acest exemplu. Apelați `get_with_retry("/organization")` pentru a-l utiliza.

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

Nu copiați această buclă în jurul unei operații de scriere. O expirare a timpului după o scriere poate
însemna că serverul a confirmat-o înainte ca、conexiunea să eșueze. Repetați o scriere numai
dacă referința acelei operații documentează explicit idempotența, păstrând
aceeași cheie și aceleași date. În caz contrar, reconciliați starea resursei înainte de a încerca din nou.

## Program de reîmprospătare recomandat

Dimensionați frecvența reîmprospătării în funcție de bugetul cheii și de dimensiunea paginii. O încărcare istorică
completă a unei colecții mari este un cost unic; preferați ferestre incrementale pentru
reîmprospătările în regim stabil, astfel încât fiecare rulare să rămână cu mult sub buget. Setați întotdeauna
`limit=500` în mod explicit — valoarea implicită de 25 multiplică numărul de solicitări.


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