Limites de débit et concurrence

Les valeurs par défaut actuelles sont de 180 requêtes/minute par IP, 60 par clé et 90 par compte. La limite IP s'applique également aux demandes authentifiées ; les clés d'un compte partagent la limite de taux du compte. Un compte peut exécuter au maximum 5 requêtes de données simultanément, et chaque clé a également sa limite max_concurrent_requests configurée. Les corps sont limités à 256 Ko et les pages à 50 éléments.

L'indemnité journalière plafonne les appels de données REST réussis en une journée ; les taux limitent les demandes de plafonnement dans la minute ; Les demandes de plafonnement de la concurrence sont toujours en cours d'exécution. La vérification n'utilise aucun appel de données quotidien mais son débit est toujours limité. L'abaissement de la limite ou la création d'une autre clé ne contourne pas l'indemnité journalière du compte. Les requêtes en série réduisent la simultanéité mais n'augmentent pas l'indemnité journalière.

Après 10 appels REST de données, HTTP 429 renvoie API_DAILY_LIMIT_REACHED. Attendez 00:00 Asia/Shanghai. Créer ou renouveler une clé ne réinitialise pas le quota du compte.

Pour RATE_LIMITED, respectez Retry-After et espacez les tentatives. Les clés valides, permissions, limites de débit, de simultanéité et de compte restent requises.

Choisissez un chemin de récupération en utilisant error.code, et non HTTP 429 seul. RateLimit-Limit, RateLimit-Remaining et RateLimit-Reset décrivent la fenêtre de taux court. La réinitialisation est un horodatage Unix en secondes, et non l'heure de réinitialisation quotidienne. L'épuisement de la fenêtre de taux fournit une nouvelle tentative en quelques secondes ; les réponses de concurrence ou d'allocation quotidienne 429 peuvent l'omettre. Lisez daily_usage pour une utilisation quotidienne et error.details.daily_usage pour une erreur de limite quotidienne.

Chaque requête REST de données réussie compte une fois, même avec un résultat vide ou une réponse en cache. Réutiliser le même Idempotency-Key et les mêmes paramètres renvoie le résultat initial sans nouvel appel décompté. Les échecs et les réponses 304 ne consomment pas le quota quotidien.

Pour RATE_LIMITED, respectez Retry-After et espacez les tentatives. Les clés valides, permissions, limites de débit, de simultanéité et de compte restent requises.

Pour RATE_LIMITED, attendez d’abord Retry-After. En cas d'absence, réduisez la simultanéité et utilisez une interruption exponentielle avec un petit délai aléatoire et un plafond de nouvelle tentative ; par exemple, attendez 1, 2, puis 4 secondes avant d'arrêter et d'enregistrer l'ID de la demande. Ne réessayez pas API_DAILY_LIMIT_REACHED toutes les secondes : attendez la réinitialisation quotidienne. Corrigez l'authentification, les autorisations ou les paramètres avant de réessayer les demandes 401, 403 ou non valides.

Conservez la clé d'idempotence et les paramètres inchangés lorsque vous réessayez la même opération de données REST. Générer une nouvelle clé pour une nouvelle opération logique ; la modification des paramètres lors de la réutilisation de la clé provoque IDEMPOTENCY_CONFLICT. Traitez différentes pages comme des opérations différentes. Les réponses 5xx réessayables nécessitent également un espacement limité.

Si deux clés d'un compte effectuent chacune 5 appels de données, le quota journalier REST partagé de 10 appels est épuisé, même si aucune demande n'a été effectuée au cours de la dernière minute. Le site Web dispose d’une allocation distincte de 10 recherches. MCP n'utilise ni l'une ni l'autre allocation journalière, mais un trop grand nombre de requêtes MCP simultanées peuvent toujours déclencher RATE_LIMITED.