Limites actuelles
Deux fenêtres s’appliquent simultanément à chaque requête :
Une requête n’est acceptée que si les deux fenêtres ont encore du budget. Si l’une d’elles est épuisée, l’API renvoie
429 Too Many Requests.
Pour discuter d’une autre limite pour une charge prévue, écrivez à team@qwairy.co en indiquant le volume de requêtes attendu.
En-têtes de limite de débit
Après une authentification réussie, les réponses de l’API incluent des en-têtes pour les deux fenêtres. Une réponse429 inclut aussi Retry-After.
Exemple d’en-têtes
Gérer les limites de débit
Lorsqu’une fenêtre est dépassée, l’API renvoie429 Too Many Requests avec un corps qui indique la fenêtre atteinte :
limit vaut "burst" ou "daily". Respectez Retry-After, calculé à partir de la fenêtre qui a bloqué la requête.
Bonnes pratiques de nouvelle tentative
Respectez Retry-After
Utilisez l’en-tête
Retry-After tel quel. Il reflète déjà la fenêtre (minute ou jour) réellement bloquante.Surveillez les deux en-têtes de solde
Surveillez
X-RateLimit-Remaining et X-RateLimit-Daily-Remaining pour ralentir avant d’être bloqué.Mettez les réponses en cache
Conservez et réutilisez les données qui changent peu (marques, concurrents, Topics).
Regroupez et filtrez
Utilisez les filtres de requête (
provider, period, limit) pour ne récupérer que les données utiles.Logique de nouvelle tentative
Réduire l’utilisation de l’API
Utiliser les paramètres de filtre
Plutôt que de tout récupérer puis de filtrer côté client, utilisez les paramètres de requête :Mettre en cache les données stables
Ne gardez les données en cache que le temps que votre intégration peut tolérer des données périmées :- Liste des marques : change quand l’accès aux marques change
- Liste des concurrents : change avec la configuration et les données observées
- Topics et Tags : changent quand la configuration du workspace change

