> ## 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 de Living Security, contrat de 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 ou l'autre des 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 du client | 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 comptabilisées dans le budget de la source. Les budgets numériques exacts sont configurés par l'opérateur et peuvent changer; le contrat de réponse décrit ci-dessous
  est l'interface stable sur laquelle fonder votre développement.
</Note>

Authentifiez-vous avec l'une ou l'autre des formes d'identifiants Basic — consultez le
[Guide de démarrage rapide](/fr-CA/developers/v1/quickstart) (`apikey:secret` ou `secret:`).
Définissez `BASE` sur l'hôte régional de l'organisation — consultez
[Régions](/fr-CA/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 de détails du problème :

```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 façon : attendez, puis réessayez.

## Gestion des réponses 429

<Steps>
  <Step title="Respecter Retry-After">
    Attendez 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 pour des requêtes qui
    seront refusées.
  </Step>

  <Step title="Augmenter le délai de façon exponentielle en cas de répétition">
    Si une nouvelle tentative est de nouveau refusée, allongez votre délai d'attente et ajoutez une variation aléatoire
    (gigue) afin que les processus parallèles ne réessaient pas tous en même temps. Ne réduisez jamais le `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 travail pour plus tard.
  </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-CA/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 pour les autres erreurs. Les délais d'attente réseau sont propagés à l'appelant. Configurez
les délais d'attente et les budgets de nouvelles tentatives en fonction de votre charge de travail. `requests` interprète le délai
d'attente 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'attente dépassé après une écriture peut
signifier que le serveur l'a validée avant l'échec 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 du budget de votre clé et de la taille de page. Un chargement historique complet
d'une grande collection représente un coût ponctuel; privilégiez les fenêtres incrémentielles pour
les actualisations en régime stable, afin que chaque exécution reste bien 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.