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

# Limites de débit

> Budgets de requêtes de l'API publique Living Security, contrat de la réponse 429 et méthode de nouvelle tentative avec Retry-After.

L'API `/v1` applique deux budgets de requêtes indépendants. Une requête est refusée
si l'un des deux budgets est épuisé.

| Budget | S'applique à |
| - | - |
| Par clé d'API | Toute requête présentant cette clé, quelle que soit l'adresse d'origine |
| Par adresse IP cliente | Toute requête provenant de cette adresse, authentifiée ou non |

Le budget par clé suit la clé partout où elle est utilisée. Le budget par adresse IP
est le seul budget applicable au trafic non authentifié et constitue un second plafond pour
le trafic authentifié.

<Note>
  Les limites sont appliquées avant l'authentification ; les requêtes dont les identifiants sont invalides ou
  absents sont donc également décomptées du budget de la source. Les budgets numériques exacts sont
  configurés par l'opérateur et peuvent évoluer ; le contrat de réponse décrit ci-dessous
  constitue l'interface stable sur laquelle développer.
</Note>

Authentifiez-vous avec l'une ou l'autre forme d'identifiants Basic — consultez le
[Guide de démarrage rapide](/fr/developers/v1/quickstart) (`apikey:secret` ou `secret:`).
Définissez `BASE` sur l'hôte régional de l'organisation — consultez
[Régions](/fr/developers/v1/regions).

## La réponse 429

Lorsqu'un budget est épuisé, l'API renvoie `429 Too Many Requests` avec un
en-tête `Retry-After` (en secondes) et le corps 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
}
```

La réponse n'indique pas quel budget a été épuisé. Traitez chaque `429` de la
même manière : patientez, puis réessayez.

## Gestion des réponses 429

<Steps>
  <Step title="Respecter Retry-After">
    Patientez au moins le nombre de secondes indiqué dans l'en-tête `Retry-After` avant
    de réessayer. Réessayer plus tôt ne fait que consommer à nouveau du budget sur des requêtes qui seront
    refusées.
  </Step>

  <Step title="Appliquer un délai exponentiel en cas de répétition">
    Si une nouvelle tentative est de nouveau refusée, augmentez votre délai d'attente et ajoutez une variation aléatoire (jitter)
    afin que les processus parallèles ne réessayent pas simultanément. Ne raccourcissez jamais la valeur `Retry-After` du serveur pour respecter un plafond
    local. Si le serveur vous demande d'attendre plus longtemps que ne le permet votre budget de nouvelles tentatives,
    arrêtez et planifiez le traitement ultérieurement.
  </Step>

  <Step title="Lisser votre débit de requêtes">
    Privilégiez un débit de requêtes régulier plutôt que des rafales. Pour les lectures en masse, utilisez la taille de page
    maximale (`limit=500`) afin de couvrir la collection en moins de requêtes — consultez la
    [pagination](/fr/developers/v1/pagination). Lorsque plusieurs parcours de listes s'exécutent en
    parallèle (par exemple des tables Power BI), maintenez une simultanéité modérée et respectez
    `Retry-After` afin qu'une réponse 429 temporaire ne fasse pas échouer l'ensemble de l'actualisation.
  </Step>
</Steps>

Cet exemple ne réessaie que les réponses `429` pour une requête **GET**, avec au plus
cinq tentatives et au plus 60 secondes d'attente entre les tentatives. Il s'arrête
immédiatement en cas d'autres erreurs. Les délais d'expiration réseau sont transmis à l'appelant. Configurez
les délais d'expiration et les budgets de nouvelles tentatives en fonction de votre charge de travail. `requests` interprète le délai d'expiration
de lecture comme le temps d'inactivité maximal pendant la réception des données, et non comme une échéance globale.

Chargez `LIVING_SECURITY_API_KEY` depuis votre gestionnaire de secrets. Installez `requests`
avant d'exécuter cet exemple. Appelez `get_with_retry("/organization")` pour l'utiliser.

```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 reproduisez pas cette boucle autour d'une opération d'écriture. Un délai d'expiration après une écriture peut
signifier que le serveur l'a validée avant l'interruption de la connexion. Ne répétez une écriture que
si la référence de cette opération documente explicitement l'idempotence, en conservant
la même clé et la même charge utile. Sinon, rapprochez l'état de la ressource avant de réessayer.

## Calendrier d'actualisation recommandé

Dimensionnez la cadence d'actualisation en fonction de votre budget par clé et de la taille de page. Un chargement
historique complet d'une grande collection représente un coût unique ; privilégiez des fenêtres incrémentielles pour
les actualisations en régime permanent, afin que chaque exécution reste nettement en deçà du budget. Définissez toujours
`limit=500` explicitement — la valeur par défaut de 25 multiplie le nombre de requêtes.


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