Skip to main content
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é. 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.
Authentifiez-vous avec l’une ou l’autre des formes 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 de détails du problème :
429 Too Many Requests
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

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