> ## 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ímites de velocidad

> Presupuestos de solicitudes de la API pública de Living Security, el contrato de la respuesta 429 y cómo reintentar con Retry-After.

La API de `/v1` aplica dos presupuestos de solicitudes independientes. Una solicitud
se rechaza si cualquiera de los dos presupuestos se ha agotado.

| Presupuesto | Se aplica a |
| - | - |
| Por clave de API | Todas las solicitudes que presenten esa clave, desde cualquier dirección |
| Por IP de cliente | Todas las solicitudes desde esa dirección, autenticadas o no |

El presupuesto por clave acompaña a la clave dondequiera que se utilice. El presupuesto por IP
es el único presupuesto para el tráfico no autenticado y un segundo límite para
el tráfico autenticado.

<Note>
  Los límites se aplican antes de la autenticación, por lo que las solicitudes con credenciales no válidas o
  ausentes también cuentan para el presupuesto del origen. Los presupuestos numéricos exactos los configura el operador y pueden cambiar; el contrato de respuesta que se describe a continuación
  es la interfaz estable sobre la que debe desarrollar.
</Note>

Autentíquese con cualquiera de los dos formatos de credenciales Basic; consulte la
[Guía de inicio rápido](/es/developers/v1/quickstart) (`apikey:secret` o `secret:`).
Establezca `BASE` con el host regional de la organización; consulte
[Regiones](/es/developers/v1/regions).

## La respuesta 429

Cuando se agota un presupuesto, la API devuelve `429 Too Many Requests` con un
encabezado `Retry-After` (en segundos) y el cuerpo estándar de detalles 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 respuesta no indica qué presupuesto se ha agotado. Trate todos los `429` de la
misma manera: espere y vuelva a intentarlo.

## Gestión de las respuestas 429

<Steps>
  <Step title="Respete Retry-After">
    Espere como mínimo el número de segundos indicado en el encabezado `Retry-After` antes de
    reintentar. Reintentar antes solo vuelve a consumir presupuesto en solicitudes que serán
    rechazadas.
  </Step>

  <Step title="Aplique un retroceso exponencial en los reintentos repetidos">
    Si un reintento vuelve a ser rechazado, aumente el tiempo de retroceso y añada una variación aleatoria (jitter)
    para que los procesos paralelos no reintenten al mismo tiempo. Nunca reduzca el valor de `Retry-After` del servidor para ajustarlo a un
    límite local. Si el servidor le pide esperar más de lo que permite su presupuesto de reintentos,
    deténgase y programe la tarea para más tarde.
  </Step>

  <Step title="Suavice su tasa de solicitudes">
    Es preferible una tasa de solicitudes constante a las ráfagas. Para lecturas masivas, utilice el tamaño de página
    máximo (`limit=500`) para cubrir la colección con menos solicitudes; consulte
    [paginación](/es/developers/v1/pagination). Cuando se ejecuten varios recorridos de listas en
    paralelo (por ejemplo, tablas de Power BI), mantenga una concurrencia moderada y respete
    `Retry-After` para que un 429 temporal no haga fallar toda la actualización.
  </Step>
</Steps>

Este ejemplo reintenta únicamente las respuestas `429` en una solicitud **GET**, con un máximo de
cinco intentos y un máximo de 60 segundos de espera entre intentos. Se detiene
de inmediato ante otros errores. Los tiempos de espera agotados de red se propagan al llamador. Configure
los tiempos de espera y los presupuestos de reintentos según su carga de trabajo. `requests` interpreta el tiempo de espera de lectura
como el tiempo máximo de inactividad durante la recepción de datos, no como un plazo global.

Cargue `LIVING_SECURITY_API_KEY` desde su gestor de secretos. Instale `requests`
antes de ejecutar este ejemplo. Llame a `get_with_retry("/organization")` para utilizarlo.

```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 copie este bucle alrededor de una operación de escritura. Un tiempo de espera agotado tras una escritura puede
significar que el servidor la confirmó antes de que fallara la conexión. Repita una escritura solo
cuando la referencia de esa operación documente explícitamente la idempotencia, conservando
la misma clave y la misma carga útil. De lo contrario, concilie el estado del recurso antes de volver a intentarlo.

## Programación de actualización recomendada

Dimensione la frecuencia de actualización en función del presupuesto de su clave y del tamaño de página. Una carga histórica
completa de una colección grande supone un coste único; para las actualizaciones
en régimen estable, prefiera ventanas incrementales, de modo que cada ejecución se mantenga muy por debajo del presupuesto. Establezca siempre
`limit=500` de forma explícita: el valor predeterminado de 25 multiplica el número de solicitudes.


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