Límites de tarifas y simultaneidad

Los valores predeterminados actuales son 180 solicitudes/minuto por IP, 60 por clave y 90 por cuenta. El límite de IP también se aplica a solicitudes autenticadas; Las claves de una cuenta comparten el límite de tasa de la cuenta. Una cuenta puede ejecutar como máximo 5 solicitudes de datos simultáneamente y cada clave también tiene su límite max_concurrent_requests configurado. Los cuerpos están limitados a 256 KB y las páginas a 50 elementos.

La asignación diaria limita las llamadas de datos REST exitosas en un día; solicitudes de límites de tarifas en un minuto; Las solicitudes de límites de simultaneidad aún se están ejecutando. La verificación no utiliza llamadas de datos diarias, pero aún tiene una tarifa limitada. Reducir el límite o crear otra clave no pasa por alto la asignación diaria de la cuenta. Las solicitudes en serie reducen la simultaneidad pero no aumentan la asignación diaria.

Tras 10 llamadas REST de datos, se devuelve HTTP 429 con API_DAILY_LIMIT_REACHED. Espera hasta las 00:00 de Asia/Shanghai. Crear o rotar una clave no reinicia la cuota de la cuenta.

Para RATE_LIMITED, respeta Retry-After y espacia los reintentos. Siguen vigentes los requisitos de clave válida, permisos y límites de frecuencia, concurrencia y cuenta.

Elija una ruta de recuperación utilizando error.code, no solo HTTP 429. RateLimit-Limit, RateLimit-Remaining y RateLimit-Reset describen la ventana de tasa corta. El reinicio es una marca de tiempo de Unix en segundos, no el tiempo de reinicio diario. El agotamiento de la ventana de tarifas proporciona el reintento posterior en segundos; Las respuestas 429 de simultaneidad o asignación diaria pueden omitirlo. Lea daily_usage para conocer el uso diario y error.details.daily_usage para conocer un error de límite diario.

Cada solicitud REST de datos correcta cuenta una vez, incluidos resultados vacíos y respuestas en caché. Reutilizar el mismo Idempotency-Key y los mismos parámetros devuelve el resultado original sin otra llamada contabilizada. Los errores y las respuestas 304 no consumen la cuota diaria.

Para RATE_LIMITED, respeta Retry-After y espacia los reintentos. Siguen vigentes los requisitos de clave válida, permisos y límites de frecuencia, concurrencia y cuenta.

Para RATE_LIMITED, espere primero a Reintentar después. Si está ausente, reduzca la concurrencia y utilice un retroceso exponencial con un pequeño retraso aleatorio y un límite de reintentos; por ejemplo, espere 1, 2 y luego 4 segundos antes de detenerse y registrar el ID de la solicitud. No vuelva a intentar API_DAILY_LIMIT_REACHED cada segundo: espere el reinicio diario. Corrija la autenticación, los permisos o los parámetros antes de volver a intentar solicitudes 401, 403 o no válidas.

Mantenga la clave de idempotencia y los parámetros sin cambios cuando vuelva a intentar la misma operación de datos REST. Generar una nueva clave para una nueva operación lógica; cambiar los parámetros mientras se reutiliza la clave provoca IDEMPOTENCY_CONFLICT. Trate diferentes páginas como operaciones diferentes. Las respuestas 5xx reintentables también requieren un retroceso limitado.

Si dos claves de una cuenta completan cada una 5 llamadas de datos, la asignación diaria REST compartida de 10 llamadas se agota, incluso si no se realizó ninguna solicitud en el último minuto. El sitio web tiene una asignación separada de 10 búsquedas. MCP no utiliza ninguna asignación diaria, pero demasiadas solicitudes simultáneas de MCP aún pueden activar RATE_LIMITED.