/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é.
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é.
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.
apikey:secret ou secret:).
Définissez BASE sur l’hôte régional de l’organisation — consultez
Régions.
La réponse 429
Lorsqu’un budget est épuisé, l’API renvoie429 Too Many Requests avec un
en-tête Retry-After (en secondes) et le corps standard de détails du problème :
429 Too Many Requests
429 de la
même façon : attendez, puis réessayez.
Gestion des réponses 429
1
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.2
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.3
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. 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.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
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 toujourslimit=500 explicitement — la valeur par défaut de 25 multiplie le nombre de requêtes.
