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

# Límits de velocitat

> Pressupostos de sol·licituds de l'API pública de Living Security, el contracte de resposta 429 i com tornar-ho a intentar amb Retry-After.

L'API `/v1` aplica dos pressupostos de sol·licituds independents. Una sol·licitud
es rebutja si qualsevol dels dos pressupostos s'ha esgotat.

| Pressupost | S'aplica a |
| - | - |
| Per clau d'API | Totes les sol·licituds que presenten aquesta clau, des de qualsevol adreça |
| Per IP del client | Totes les sol·licituds des d'aquesta adreça, autenticades o no |

El pressupost per clau segueix la clau allà on s'utilitzi. El pressupost per IP és
l'únic pressupost per al trànsit no autenticat i un segon límit per al trànsit
autenticat.

<Note>
  Els límits s'apliquen abans de l'autenticació; per tant, les sol·licituds amb
  credencials no vàlides o absents també compten contra el pressupost d'origen. Els
  pressupostos numèrics exactes els configura l'operador i poden canviar; el
  contracte de resposta que es descriu a continuació és la interfície estable sobre
  la qual podeu desenvolupar.
</Note>

Autentiqueu-vos amb qualsevol de les dues modalitats de credencial Basic; consulteu
[Quickstart](/ca/developers/v1/quickstart) (`apikey:secret` o `secret:`).
Configureu `BASE` amb l'amfitrió regional de l'organització; consulteu
[Regions](/ca/developers/v1/regions).

## La resposta 429

Quan un pressupost s'esgota, l'API retorna `429 Too Many Requests` amb una capçalera
`Retry-After` (en segons) i el cos estàndard de detalls del problema:

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

La resposta no indica quin pressupost s'ha esgotat. Tracteu tots els `429` de la
mateixa manera: espereu i torneu-ho a intentar.

## Gestió dels 429

<Steps>
  <Step title="Respecteu Retry-After">
    Espereu, com a mínim, el nombre de segons indicat a la capçalera `Retry-After` abans de
    tornar-ho a intentar. Reintentar-ho abans només torna a consumir pressupost en
    sol·licituds que es rebutjaran.
  </Step>

  <Step title="Apliqueu un retard exponencial en cas de repeticions">
    Si un reintent es rebutja de nou, augmenteu el retard i afegiu-hi un jitter
    aleatori perquè els processos paral·lels no reintentin de manera sincronitzada.
    No escurceu mai el `Retry-After` del servidor per ajustar-lo a un límit local. Si el
    servidor us demana que espereu més del que permet el vostre pressupost de
    reintents, atureu-vos i programeu la feina per a més tard.
  </Step>

  <Step title="Suavitzeu la vostra taxa de sol·licituds">
    És preferible una taxa de sol·licituds constant a les ràfegues. Per a lectures
    massives, utilitzeu la mida de pàgina màxima (`limit=500`) per cobrir la col·lecció amb
    menys sol·licituds; consulteu [pagination](/ca/developers/v1/pagination). Quan
    diversos recorreguts de llistes s'executen en paral·lel (per exemple, taules de
    Power BI), mantingueu una concurrència moderada i respecteu `Retry-After` perquè un 429
    temporal no faci fallar tota l'actualització.
  </Step>
</Steps>

Aquest exemple només reintenta les respostes `429` en una sol·licitud **GET**, amb
un màxim de cinc intents i un màxim de 60 segons d'espera entre intents. S'atura
immediatament davant d'altres errors. Els temps d'espera de xarxa es propaguen a
qui fa la crida. Configureu els temps d'espera i els pressupostos de reintents
segons la vostra càrrega de treball. `requests` interpreta el temps d'espera de lectura
com el temps màxim d'inactivitat durant la recepció de dades, no com un termini
global.

Carregueu `LIVING_SECURITY_API_KEY` des del vostre gestor de secrets. Instal·leu `requests`
abans d'executar aquest exemple. Crideu `get_with_retry("/organization")` per utilitzar-lo.

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

No copieu aquest bucle al voltant d'una operació d'escriptura. Un temps d'espera
esgotat després d'una escriptura pot significar que el servidor la va confirmar
abans que la connexió fallés. Repetiu una escriptura només quan la referència
d'aquesta operació documenti explícitament la idempotència, conservant la mateixa
clau i la mateixa càrrega. En cas contrari, concilieu l'estat del recurs abans de
tornar-ho a intentar.

## Calendari d'actualització recomanat

Dimensioneu la cadència d'actualització segons el pressupost de la vostra clau i la
mida de pàgina. Una càrrega històrica completa d'una col·lecció gran és un cost
únic; per a les actualitzacions en règim estacionari, són preferibles les finestres
incrementals, de manera que cada execució quedi ben per sota del pressupost.
Configureu sempre `limit=500` de manera explícita: el valor per defecte de 25 multiplica
el nombre de sol·licituds.


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