429 Demasiadas solicitudes: lo que significa y cómo gestionarlo

Una API devuelve 429 Too Many Requests cuando tu aplicación ha enviado más solicitudes de las que la API permite en un período de tiempo. La propia solicitud está bien. Lo enviaste con demasiada frecuencia, por lo que la API la rechazó. Si espera y lo envía de nuevo, normalmente funciona. La respuesta suele incluir un Retry-After encabezado que indica cuánto tiempo se debe esperar. Para obtener más información, consulte RFC 6585, sección 4.

Cada API implementa los límites de tasa de forma diferente. El código de estado, los encabezados y el cuerpo del error varían, por lo que el código que controla una API correctamente puede controlar incorrectamente el siguiente.

API Status Cómo saber cuánto tiempo se debe esperar Cuidado con
GitHub 403 o 429 retry-after si está presente; en caso contrario, x-ratelimit-reset (segundos desde la época UTC) cuando x-ratelimit-remaining sea 0; en caso contrario, al menos 1 minuto Un 403 puede ser un límite de tasa o un permiso que falta. Lea los encabezados para distinguirlos.
OpenAI 429 retry-after Algunos 429, como credit_balance_exhausted, significan que el reintento no ayudará. Compruebe error.code.
Antrópica 429 retry-after Un límite de gasto 429 no tiene retry-after y sigue fallando hasta que se reanuda el acceso. Una API sobrecargada devuelve 529, no 429.
Microsoft Graph 429 Retry-After (segundos) Los límites difieren por servicio, por ejemplo, SharePoint y Outlook.

Cómo gestionar un error 429

  1. Decida si desea volver a intentarlo. Si el error indica que la cuota, los créditos o el límite de gasto se ha agotado, el reintento no ayudará. Dile al usuario y avísate.
  2. Espere tanto tiempo como lo solicite la API. Si la respuesta tiene Retry-After, espere ese tiempo. Es un número de segundos o una fecha HTTP. Si la API usa encabezados de limitación de tasa en su lugar, como GitHub x-ratelimit-reset, espere hasta la hora de restablecimiento.
  3. De lo contrario, retroceda. Sin una sugerencia de la API, vuelva a intentarlo con retroceso exponencial y aleatorización aleatoria, y detenga después de algunos intentos.
  4. Indique al usuario lo que está sucediendo. "Ocupado, reintentar en 5 segundos" supera a un indicador de carga que nunca termina.
  5. Ralentice antes del próximo 429. Si la API envía encabezados de límite de solicitudes, use el recuento restante para regular el ritmo de las solicitudes.
async function fetchWithRetry(url, options, attempts = 3) {
  for (let attempt = 1; ; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === attempts) {
      return response;
    }
    const retryAfter = response.headers.get('retry-after');
    const waitMs = retryAfter
      ? (isNaN(retryAfter) ? new Date(retryAfter) - Date.now() : retryAfter * 1000)
      : 2 ** attempt * 1000 + Math.random() * 1000;
    await new Promise(resolve => setTimeout(resolve, Math.max(waitMs, 0)));
  }
}

Muchos SDK reintentan por ti las solicitudes que reciben respuestas 429. Por ejemplo, openAI Python SDK reintenta dos veces de forma predeterminada y el controlador estándar de resiliencia de .NET reintenta 3 veces y respeta Retry-After. Cuando el SDK se queda sin reintentos, tu código recibe el error, por lo que todavía necesita un plan.

Cómo probar que la aplicación controla el código de estado HTTP 429

Rara vez ves un 429 mientras desarrollas. La API es rápida, usted es el único usuario y los datos de prueba son pequeños. Por lo tanto, la forma de probar la gestión del 429 decide si encuentra los errores antes de que tus usuarios lo hagan.

Approach Lo que encuentras Lo que te pierdes
Esperar a que esté en producción Fallos reales Todo, hasta que un usuario haga clic en ello
Simula la API en tus pruebas o deja que tu agente de codificación escriba el mock Si se ejecuta la rama de reintento Los códigos de estado real, los encabezados y los cuerpos de error de la API y la directiva de reintento de tu SDK. La aplicación también necesita una opción solo para pruebas para llegar al mock.
Llame a la API real hasta que te aplique limitación de tasa. Comportamiento real No se puede desencadenar un 429 a petición y se usa la cuota real.
Intercepte el tráfico real de la aplicación y devuelva 429s a petición Direcciones URL reales, el SDK real y la directiva de reintento, y el formato 429 de la API Nada en tu aplicación cambia, por lo que no prueba tu código de forma aislada. Reserve las pruebas unitarias para eso.

Pruébalo en tu aplicación

Dev Proxy intercepta las solicitudes de la aplicación a las API que elijas y devuelve 429s, con los encabezados y el formato de error de la API, mientras que la aplicación sigue llamando a las direcciones URL reales. También indica cuándo la aplicación vuelve a intentarlo antes de que Retry-After se acabe el tiempo.

Descargue el preajuste de la API a la que llama la aplicación e inicie Dev Proxy con él:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
API Preset
GitHub github-rate-limiting
OpenAI openai-throttling
Anthropic anthropic-throttling
Microsoft Graph (OneDrive y SharePoint: /drive, /shares, /sites) microsoft-graph-rate-limiting

A continuación, ejecute la aplicación como de costumbre y observe lo que hace. Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Pasos siguientes

Prueba de que mi aplicación controla la limitación correctamente

Consulte también

  • Se actualizó por última vez el