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 has enviado con demasiada frecuencia, por lo que la API lo ha rechazado. 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.

Aspecto de 429 en las API más populares

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.

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á. Informa al usuario y avísate a ti mismo.
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, por el contrario, la API utiliza encabezados de límite de rate, como el de GitHub x-ratelimit-reset, espera hasta que transcurra el tiempo de reinicio.
3. De lo contrario, retrocede. Si la API no ofrece ninguna indicación, vuelve a intentarlo con retroceso exponencial y fluctuación aleatoria, y detente tras unos cuantos 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 comprobar que tu aplicación administra el código 429

Rara vez ves un 429 mientras desarrollas. La API es rápida, eres el único usuario y tus datos de prueba son pequeños. Por lo tanto, la forma en que compruebes la administración del código 429 determinará si detectas los errores antes que tus usuarios.

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 te indica cuándo tu aplicación vuelve a intentarlo antes de que finalice el tiempo Retry-After.

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"

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

Consulte también

• ¿Qué es la limitación de velocidad?
• ¿Qué es la limitación de velocidad?
• Prueba cómo gestiona tu aplicación los límites de tasa de la API de GitHub
• Comprueba cómo administra tu aplicación los límites de tasa de OpenAI
• Probar reintentos y tiempos de espera en aplicaciones de .NET