Skip to main content
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é. 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.
Authentifiez-vous avec l’une ou l’autre forme d’identifiants Basic — consultez le Guide de démarrage rapide (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 renvoie 429 Too Many Requests avec un en-tête Retry-After (en secondes) et le corps standard problem-details :
429 Too Many Requests
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

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