ErrorBase
Referencia técnica independienteSitio oficial
  • Software y sistemas
  • Servicio HTTP

429

HTTP 429 Too Many Requests: el servidor limita tus peticiones

Verificada con fuentes2 fuentesRevisada 4 oct 2026
¿Viene un técnico? Mira los 3 pasos que debe enseñarte

Nivel de riesgo

Seguro

Puedes actuar sin peligro siguiendo las comprobaciones seguras.

Urgencia

Media — atiéndelo hoy

Respuesta rápida

HTTP 429 significa que el servidor ha recibido demasiadas peticiones tuyas en un intervalo y aplica un límite de frecuencia. Revisa si la respuesta trae la cabecera Retry-After, espera al menos ese plazo antes de repetir y reduce la cadencia de tu navegador, script o integración.

Seguridad primero

Antes de continuar

  • Detente antes de rotar cuentas, credenciales o direcciones para esquivar el límite: el operador puede tratarlo como abuso y endurecer el bloqueo.
  • Un servidor saturado no está obligado a contestar 429: RFC 6585 admite que corte conexiones sin más, así que esos cortes durante una ráfaga pueden ser el mismo límite.

Puedes hacerlo con seguridad

  • Cabecera Retry-After y cuerpo de la respuesta 429
  • Espera completa antes de un único reintento
  • Recuento de peticiones por credencial
  • Política de reintentos del cliente

Deja estas tareas a un profesional cualificado

  • No intentes esta tarea profesional: Operador del servicio o de la API
  • No intentes esta tarea profesional: Desarrollador del cliente que recibe el 429
  • No intentes esta tarea profesional: Administrador del servidor que emite el 429

Lo que un técnico debe poder justificar

Viene un técnico

Estos son los pasos que tiene que hacer y enseñarte. Márcalos mientras trabaja: si se salta pasos, no aceptes el cambio de pieza.

No son instrucciones para que abras o manipules el equipo. Son las comprobaciones que deben sostener una conclusión técnica.

  1. Operador del servicio o de la API

    Qué hacePide al operador qué regla de limitación te aplica: si cuenta por recurso, por credencial o por todo el servicio, y cuántas peticiones admite por intervalo.

    Te tiene que enseñarla identidad que cuenta y la cuota de tu cuenta.

    Por escritola cuota vigente y, si la amplía, la nueva cifra con su fecha.

  2. Desarrollador del cliente que recibe el 429

    Qué haceHaz que el cliente lea Retry-After, espere ese plazo y limite los reintentos, repartiendo en el tiempo las tareas que comparten credencial.

    Te tiene que enseñaruna prueba registrada en la que el cliente recibe 429 y espera el plazo antes de repetir.

    Por escritoel intervalo de espera y el número máximo de reintentos configurados.

  3. Administrador del servidor que emite el 429

    Qué haceSi el 429 sale de tu propio servidor, revisa que la respuesta explique el límite, incluya Retry-After cuando sea posible y no se guarde en caché.

    Te tiene que enseñaruna respuesta 429 de prueba con explicación y Retry-After.

    Por escritola regla de limitación, con identidad, ventana y número de peticiones.

Antes de aceptar una pieza o reparación

Aún no ha demostrado nada. No aceptes un cambio de pieza solo por el código.

Sigue estos pasos

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

  1. Cabecera Retry-After y cuerpo de la respuesta 429

    Sin herramientas especiales

    Quién:
    el desarrollador o quien mantenga el script o la integración; en un navegador, cualquiera que sepa abrir la pestaña Red de las herramientas de desarrollo.
    Cómo:
    guarda la respuesta 429 completa, con cabeceras y cuerpo, y busca Retry-After y el texto que explica el límite.
    Resultado que importa:
    conocer el plazo de espera y la regla que aplica el servidor.
    Si Retry-After trae segundos o una fecha HTTP:
    confirma el tiempo mínimo que debes dejar pasar antes de repetir.
    Si no hay Retry-After ni explicación:
    indica que el servidor no publica el plazo y que la cuota hay que pedírsela al operador del servicio.
    Evidencia a conservar:
    copia de las cabeceras y del cuerpo con la hora exacta, sin tokens ni cookies.

    Evidencia: RFC 9110 section 10.2.3 - Retry-After · RFC 6585 section 4 - 429 Too Many Requests · RFC 9110 section 15.5 - Client Error 4xx

  2. Espera completa antes de un único reintento

    Sin herramientas especiales

    Quién:
    tú, como visitante de la web o usuario de la aplicación.
    Cómo:
    deja de recargar o pulsar el botón, espera el plazo de Retry-After o, si no lo hay, unos minutos, y repite una sola vez.
    Resultado que importa:
    saber si el bloqueo era una ventana temporal.
    Si la petición funciona tras esperar:
    confirma que era un límite de frecuencia que ya se ha liberado.
    Si vuelve el 429 al primer intento:
    indica que tu cuenta o sesión sigue enviando peticiones desde otro sitio o que la ventana es más larga.
    Evidencia a conservar:
    hora del primer 429, hora del reintento y resultado.

    Evidencia: RFC 9110 section 10.2.3 - Retry-After · RFC 6585 section 4 - 429 Too Many Requests

  3. Recuento de peticiones por credencial

    Sin herramientas especiales

    Quién:
    el desarrollador o el administrador del sistema que lanza las peticiones.
    Cómo:
    en los registros de tu cliente, suma las peticiones enviadas con la misma credencial o cookie en la ventana previa al 429, incluidos todos los procesos, tareas programadas y pestañas.
    Resultado que importa:
    saber si el límite cuenta el total de varios procesos.
    Si varios procesos comparten credencial y la suma es alta:
    confirma que el contador del servidor los agrupa.
    Si un único proceso envía pocas peticiones:
    indica que el límite es por servidor o por grupo de servidores y conviene preguntar al operador.
    Evidencia a conservar:
    tabla con peticiones por minuto y por proceso sacada del registro.

    Evidencia: RFC 6585 section 4 - 429 Too Many Requests

  4. Política de reintentos del cliente

    Sin herramientas especiales

    Quién:
    el desarrollador del script, la aplicación o la integración.
    Cómo:
    revisa en el código o en la configuración qué hace el cliente al recibir 429: si reintenta, cada cuánto y cuántas veces.
    Resultado que importa:
    saber si tus reintentos alimentan el bloqueo.
    Si reintenta antes del plazo de Retry-After o sin espera:
    confirma que el propio cliente prolonga el límite.
    Si respeta el plazo y aun así recibe 429:
    descarta los reintentos y vuelve al recuento por credencial.
    Evidencia a conservar:
    registro con las marcas de hora de cada reintento.

    Evidencia: RFC 9110 section 10.2.3 - Retry-After · RFC 6585 section 4 - 429 Too Many Requests

Situación no resuelta

Si el error persiste, no sigas probando por tu cuenta. Mira qué tiene que hacer y enseñarte el técnico.

Dónde se aplica este código

Un código solo tiene significado dentro del producto y la versión correctos.

Ámbito principal

Sistema
Software y sistemas
Marca
HTTP
Tipo de producto
Servicio HTTP

Variantes conocidas del código

  • 429 Demasiadas solicitudes
  • 429 Too Many Requests
  • 429 Trop de requêtes
  • 429 Troppe richieste
  • 429 Zu viele Anfragen
  • código HTTP 429
  • error HTTP 429
  • HTTP 429
  • HTTP error 429
  • HTTP status 429
  • status code 429

Qué significa

RFC 6585 define 429 Too Many Requests como limitación de frecuencia: el servidor de origen cuenta tus peticiones y deja de atenderlas al pasar su cuota. La respuesta debería explicar la condición y puede incluir Retry-After, que en RFC 9110 lleva una fecha HTTP o un número de segundos. El estándar no fija cómo se identifica al usuario ni cómo se cuentan las peticiones: el límite puede ir por recurso, por servidor entero o por un grupo de servidores, y la identidad puede ser la credencial de autenticación o una cookie de sesión. Una respuesta 429 no debe guardarse en caché.

Advertencias y condiciones de parada

  • Precauciónadvertencia editorial

    Detente antes de rotar cuentas, credenciales o direcciones para esquivar el límite: el operador puede tratarlo como abuso y endurecer el bloqueo.

    Evidencia: RFC 6585 section 4 - 429 Too Many Requests

  • Seguroverificada con fuente

    Un servidor saturado no está obligado a contestar 429: RFC 6585 admite que corte conexiones sin más, así que esos cortes durante una ráfaga pueden ser el mismo límite.

    Evidencia: RFC 6585 section 4 - 429 Too Many Requests

Síntomas y causas

Causas probables · en orden

  • Superaste la cuota de peticiones del servidorConfirmada

    RFC 6585 define 429 para cuando el usuario ha enviado demasiadas peticiones en un tiempo dado, lo que se conoce como limitación de frecuencia.

    Evidencia: RFC 6585 section 4 - 429 Too Many Requests · IANA Hypertext Transfer Protocol Status Code Registry

  • Varios procesos cuentan bajo la misma credencial o cookiePosible

    El servidor puede identificar al usuario por sus credenciales de autenticación o por una cookie con estado, de modo que trabajadores o pestañas que las comparten suman sus peticiones en un mismo contador.

    Evidencia: RFC 6585 section 4 - 429 Too Many Requests

  • Límite aplicado a todo el servidor o a un grupo de servidoresPosible

    El RFC permite contar peticiones por recurso, en todo el servidor o entre varios servidores; un límite global se alcanza aunque cada ruta reciba pocas llamadas.

    Evidencia: RFC 6585 section 4 - 429 Too Many Requests

  • Reintentos que no esperan el plazo de Retry-AfterPosible

    Retry-After indica cuánto debería esperar el agente de usuario antes de la siguiente petición; un cliente que reintenta antes vuelve a sumar en la ventana del límite.

    Evidencia: RFC 9110 section 10.2.3 - Retry-After · RFC 6585 section 4 - 429 Too Many Requests

Técnico virtual

¿Sigue apareciendo 429 tras comprobarlo?

Responde unas preguntas para acotar la causa probable y la siguiente acción segura. Es una orientación - nunca sustituye a un profesional.

Iniciar diagnóstico

Fuentes y referencias técnicas

  1. 1

    RFC 6585 section 4 - 429 Too Many Requests

    Internet Engineering Task Force · 2012 · official_doc

  2. 2

    IANA Hypertext Transfer Protocol Status Code Registry

    Internet Assigned Numbers Authority · 2025 · official_doc

Fuentes: RFC 6585 section 4 - 429 Too Many Requests · IANA Hypertext Transfer Protocol Status Code Registryrevisado 2026-10-04 · verificado

¿Te ha resultado útil esta ficha?