/v1 applique deux budgets de requêtes indépendants. Une requête est refusée
si l’un des deux 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 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.
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 problem-details :
429 Too Many Requests
429 de la
même manière : patientez, puis réessayez.
Gestion des réponses 429
1
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.2
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.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 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
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 toujourslimit=500 explicitement — la valeur par défaut de 25 multiplie le nombre de requêtes.
