¿Qué es el Error HTTP 429 «Too many requests»?

El error HTTP 429 «Too many requests» es una respuesta del servidor que indica que un mismo cliente ha hecho demasiadas peticiones en un periodo de tiempo muy breve. Por lo tanto, no se trata de un fallo técnico del servidor, ni mucho menos, sino de una medida de seguridad que se pone en marcha de forma intencionada para evitar abusos y sobrecargas de los recursos disponibles.

El error 429 no es el código HTTP más habitual, peor puede darte la tabarra si usas aplicaciones que hacen llamadas a APIs externas, que emplean sistemas automatizados, que usan bots o en entornos en los que hay muchos usuarios que quieren acceder simultáneamente. Así que no te asustes. Lo primero que hay que hacer es entender por qué se está produciendo y adaptar el comportamiento del cliente (o la configuración del servidor) en consecuencia.

En este post, quiero explicarte qué significa exactamente el error 429, cuáles son sus causas más habituales, cómo resolverlo en función de su origen y qué hacer si el problema viene del uso de bots, scrapers o crawlers. En definitiva, quiero que tengas a mano una guía completa para identificar bien el problema y aplicar la solución adecuada, sin comerte mucho la olla.

Significado del código 429 en HTTP

El error 429 «Too many requests» aparece cuando un usuario o aplicación realiza demasiadas peticiones a un servidor en un periodo de tiempo muy corto. Es una forma que tiene el servidor de protegerse y decir: “Estás haciendo demasiadas solicitudes, frena un poco”.

Verás, hay un sistema llamado «rate limiting» que sirve para poner límites de modo que no se pueda hacer abuso, sobrecarga o incluso un ataque al servidor (como los ataques DDoS). Por ejemplo, el servidor puede tener una regla que diga: “Solo se puede hacer un máximo 100 peticiones por minuto por usuario”. El objetivo es doble: proteger el rendimiento del servidor y garantizar un uso justo de los recursos para todos los usuarios.

¿Y qué pasa si se supera ese límite? Pues que se devuelve el error 429 para forzar una pausa.

En qué se diferencia el error 429 de otros errores HTTP

El error 429 «Too many requests» se diferencia de otros errores HTTP en que no indica que haya un fallo del servidor ni un error en la solicitud. Más bien es una respuesta que limita el número de peticiones. ¿Y para qué? Pues su función es proteger el sistema, ante todo.

A diferencia de errores como el error 404, que indica que el recurso al que se quiere llegar no existe, o el error 500, que suele indicar que hay un problema interno del servidor, el error 429 actúa como mecanismo de control en un sistema que funciona perfectamente. ¿A qué me refiero? Pues a que el error 429 no indica que el servidor esté roto, sino que sirve simplemente para marcar un límite de forma temporal.

Además, el error 429 también es distinto de errores como el 403 (que deniega el acceso en función de los permisos) porque el 429 no prohíbe el acceso de forma permanente. Tan solo le pide al cliente que espere un poco antes de volver a intentarlo.

¡En resumen! El código HTTP 429 no te está señalando un error definitivo o que no se pueda subsanar, sino simplemente una situación temporal provocada por un uso excesivo de los recursos. La clave está en modificar el ritmo de las peticiones y respetar los límites que establece el sistema.

Pero vamos a ver algunas de las causas que nos pueden llevar a toparnos con el error 429. Después, te enseño las soluciones.

Principales causas del error 429

Vale, ya hemos quedado en que el error 429 indica que se ha alcanzado un límite de peticiones impuesto para impedir que se haga un uso anómalo del servidor.

Ahora te estarás preguntando qué causas pueden llevar a hacer saltar esa limitación, ¿no? Pues vamos a verlas.

1. Gran número de peticiones en muy poco tiempo

La pongo de primera porque es la causa más frecuente. El cliente (ya sea un navegador, una aplicación móvil, un script automatizado, etc.) está haciendo un número excesivo de peticiones en un intervalo muy corto de tiempo. Como resultado, el servidor, al detectar esta actividad tan intensa, activa su sistema de protección y responde con un 429 para evitar una posible sobrecarga.

Como te digo, es una situación común en aplicaciones que realizan peticiones de forma continua o que no gestionan adecuadamente los intervalos entre llamadas a servicios externos.

2. Límite de uso configurado en el servidor (rate limiting)

Muchos servidores y APIs tienen marcados, de forma explícita, unos límites de uso para cada usuario, IP o aplicación (es decir, para cada cliente). Estos límites van a ser distintos en función del proveedor o del servicio, e incluso según el tipo de cuenta o plan contratado.

Por ejemplo, imagínate que una API permite hasta 60 peticiones por minuto a cada usuario. Si se supera esa cantidad, el servidor rechaza las siguientes solicitudes y devuelve un error 429 hasta que se restablece el límite. Se trata de un sistema de control bastante habitual en servicios en la nube, plataformas de pago por uso y otros sistemas con mucha demanda.

3. Uso de bots, scrapers o automatizaciones

Cuando se utilizan bots o herramientas automatizadas para acceder a sitios web o APIs sin un sistema de control (por ejemplo, para hacer pausas entre peticiones), es muy probable que se active el sistema de protección del servidor.

¿Cuándo es probable que suceda? Por ejemplo, cuando se hacen tareas de web scraping, pruebas automatizadas o tareas de monitorización intensivas. Muchos servidores detectan este tipo de actividad como potencialmente maliciosa y muestran el error 429 como mecanismo disuasorio.

4. Errores en el código del cliente

Una causa menos evidente, pero igualmente importante, es la presencia de errores en el desarrollo del cliente. Por ejemplo, si una aplicación tiene un bug que provoca que una misma petición se envíe varias veces en bucle, puede superar rápidamente los límites establecidos por el servidor.

También puede ocurrir en sistemas que no reutilizan correctamente datos en caché o que reintentan solicitudes fallidas de forma que acaban generando una alta carga de tráfico innecesario.

5. Varios usuarios que comparten una misma IP

Hay entornos (redes corporativas, instituciones educativas, conexiones mediante proxy…) en los que es habitual que haya varios usuarios compartiendo una única dirección IP pública. En estos casos, el servidor receptor puede interpretar todas las solicitudes como si provinieran del mismo cliente.

De este modo, aunque es posible que cada usuario esté haciendo un uso razonable, si la suma total de las peticiones enviadas supera el límite establecido para esa IP, puede aparecer un error 429 para todos los que la estén utilizando.

6. Picos de tráfico inesperados o comportamiento sospechoso

Hay sistemas que están configurados para detectar patrones de tráfico poco habituales, como un gran número de accesos en muy poco tiempo desde la misma zona geográfica o dirección IP. Cuando se detecta que esto está sucediendo, es habitual que el servidor pase a aplicar medidas de protección, como un bloqueo temporal mediante un error HTTP 429.

Y ojo, que esto no implica que se haya hecho necesariamente un mal uso intencionado, pero sí que ha habido un comportamiento que no es el que esperaba el sistema. Como resultado, el error 429  se aplica de forma automática como medida de seguridad.

Cómo solucionar el código HTTP 429 en función del origen del problema

Veamos. El error 429 no es un fallo del servidor, como tal, sino más bien una respuesta intencionada que indica que se ha superado un límite. Por eso, la solución depende en gran medida de quién esté haciendo las peticiones y de cómo esté configurado el sistema.

¡Por lo tanto!

Podemos decir que el error 429 se resuelve entendiendo su origen y ajustando el ritmo o la forma en que se hacen las peticiones.

Vamos a ver varios casos distintos para que veas a qué me refiero.

1. Si el problema está en el cliente o en la aplicación que hace las peticiones

Si te está saliendo un error 429 y sospechas que viene de tu propia app o cliente, lo primero que tienes que hacer es mirar cómo estás haciendo las peticiones. Muchas veces el problema viene de ahí, de que estás enviando demasiadas solicitudes seguidas sin darte cuenta.

Empieza por revisar el código. Asegúrate de que no tienes bucles que estén lanzando llamadas de forma continua o haciendo reintentos sin control. A veces un fallo pequeño (un bucle while sin límite o un reintento automático sin condiciones) puede acabar mandando un montón de peticiones en segundos.

Después, ponle un poco de orden a las llamadas. Introducir un pequeño retraso entre peticiones (lo típico: medio segundo, un segundo…) puede venir genial si estás rozando el límite de uso de una API.

También va bien usar lo que se llama «retroceso exponencial». En muy resumidas cuentas, si una petición falla no se hace un reintento inmediato, sino que se espera un poco antes de volver a probar y se va aumentando ese tiempo si sigue fallando. Así evitas insistir de más justo cuando el servidor ya te ha dicho que pares.

Y muy importante: si los datos que estás pidiendo no cambian todo el rato, usa la caché. Guarda la respuesta y reutilízala (si puedes), en lugar de hacer siempre la misma llamada. De este modo, no solo te evitas errores 429; además, consigues que tu app funcione de forma más rápida y eficiente.

Por último, si estás usando una API externa, mírate la documentación. Muchas veces, ahí te dicen el número exacto de peticiones que puedes hacer por minuto o por hora.

2. Si el límite lo impone una API externa

Cuando usas una API de terceros, lo normal es que tenga un límite de peticiones establecido, precisamente para evitar abusos.

Este tipo de restricciones suelen estar muy bien definidas por el propio proveedor, así que lo primero que deberías hacer es consultar la documentación oficial. Ahí suelen indicar cuántas peticiones puedes hacer por minuto, por hora o incluso por día, según el plan que tengas contratado. Algunas APIs también te devuelven cabeceras como Retry-After, que te indican exactamente cuánto debes esperar antes de volver a intentarlo.

Si ves que te estás quedando corto con esos límites, una opción bastante directa es ver si puedes subir de plan. Muchas APIs tienen versiones gratuitas con restricciones ajustadas, pero ofrecen opciones de pago que amplían esos márgenes. A veces, con solo cambiar a un plan básico de pago, ya puedes trabajar con más comodidad y sin tener que andar limitando tanto tus llamadas.

Otra alternativa útil es organizar mejor las peticiones que haces. Si tienes muchas llamadas concentradas en un corto periodo de tiempo, puede que te convenga repartirlas a lo largo del día o del minuto, en función de cómo esté estructurado el límite.

Y si la API lo permite, podrías usar varias claves de autenticación (tokens o API keys) para dividir la carga entre ellas, aunque esto hay que hacerlo con cuidado y respetando las condiciones del servicio, porque no todas las plataformas dejan hacerlo.

3. Si hay varias personas compartiendo la misma dirección IP

Es una situación habitual en entornos como oficinas, centros educativos o redes en las que se accede a internet a través de un proxy o cortafuegos común.

En estos casos, aunque las peticiones provengan de diferentes usuarios, desde fuera todas parecen salir desde la misma dirección IP pública. Como consecuencia, el servidor o la API que las recibe las interpreta como si fueran de un único cliente… y devuelve un error 429 por exceso de peticiones.

Si crees que esto es lo que te está pasando, lo mejor que puedes hacer es ponerte en contacto con el administrador de red. A veces, se puede configurar la salida a Internet de forma que distintas máquinas usen diferentes IPs públicas o incluso que salgan por distintos gateways para repartir el tráfico. No siempre es viable, pero vale la pena revisarlo si el uso de la API es importante.

También es buena idea que te pongas en contacto con el proveedor del servicio que te está devolviendo el error. Puedes explicarles que hay varios usuarios legítimos trabajando desde una única IP y pedirles que hagan una excepción o que ajusten el límite a esa situación. Muchas veces, si justificas bien el caso, están dispuestos a colaborar, sobre todo si se trata de un entorno profesional o educativo.

4. Si el límite está en tu propio servidor (y tú controlas el backend)

¿Y qué pasa si eres tú el que gestiona el servidor o la API que está lanzando el error 429? Pues que, al menos, tienes la ventaja de poder ajustar la configuración de acuerdo con tus necesidades. En este caso, el problema suele estar en alguna política de rate limiting que tú mismo (o alguien de tu equipo) has configurado para proteger el sistema ante un exceso de peticiones.

Lo primero es revisar dónde está aplicado ese límite. Puede estar en varios niveles: en el servidor web (como Nginx o Apache), en el backend de tu aplicación (por ejemplo, si usas Express, Flask o Django) o incluso en servicios externos como un firewall o una CDN (Cloudflare, por ejemplo, te permite configurar límites de acceso). Cuando encuentres el punto correcto en el que está ese límite, ya serás capaz de afinar con la solución.

Entonces.

Una vez localizado, ajusta esos límites teniendo en cuenta el comportamiento real de tus usuarios. No es lo mismo una API pensada para tráfico ocasional que una que se va a usar de forma intensiva o en horarios muy concretos. Puedes ser más flexible con usuarios autenticados, definir distintos umbrales según el tipo de cuenta o la funcionalidad que estén utilizando, etc.

Otro punto importante es que muchas veces se limita por IP por defecto, pero puede ser mucho más eficaz y justo aplicar los límites por usuario autenticado, token de API o cualquier otro identificador único. De este modo, no castigas a los usuarios que comparten una misma IP o que están usando un proxy.

Por último, no te olvides de ser lo más claro posible con los usuarios de tu sistema. Devuélveles cabeceras como Retry-After para que sepan cuánto tienen que esperar antes de volver a intentarlo.

¿Y qué hago si el error 429 me lo están generando bots, scrapers o crawlers?

Cuando detrás del error 429 hay bots o scrapers (tuyos o de terceros), la cosa es un poco distinta, porque en estos casos las peticiones suelen ser muy numerosas, muy rápidas y, a veces, poco respetuosas con los límites del sistema.

Si los bots los controlas tú (por ejemplo, porque estás haciendo scraping de una web o recopilando datos desde una API) te tocará revisar bien su comportamiento. Asegúrate de que estén haciendo peticiones de forma gradual (es decir, con pausas razonables) e implementa un sistema de reintentos con retroceso exponencial.

Te lo contaba más arriba. El retroceso exponencial consiste en que, tras recibir un error 429, el sistema no vuelva a intentarlo enseguida, sino que se espere unos segundos… Y que cada vez que vuelva a fallar, se espere un poco más. De este modo, te evitas errores y reduces el riesgo de que te bloqueen por mal uso.

Si lo que estás haciendo es acceder a un sitio externo, mira si tiene API pública, porque muchas veces es mejor usarla que hacer scraping directamente desde el HTML. Las APIs suelen estar preparadas para un uso controlado y muchas veces ofrecen límites más claros y datos más estructurados.

Ahora bien, ¿qué pasa si los bots vienen de fuera y están accediendo a tu servidor? Pues lo más importante es identificarlos y limitar el impacto que puedan llegar a tener. Tienes varias opciones: puedes bloquear IPs, analizar los user-agent, establecer reglas de rate limiting más estrictas para tráfico sospechoso o usar herramientas como firewalls o servicios como Cloudflare para mitigar ese tráfico de forma automática.

Otra medida útil es controlar el acceso al contenido que no debería estar indexado. Por ejemplo, puedes usar el archivo robots.txt para decirles a los crawlers qué pueden y qué no pueden visitar. No todos lo respetan, claro, pero es una buena primera medida.

Casos comunes: Error 429 en WordPress y WooCommerce

En sitios creados con WordPress (y más si tienes WooCommerce instalado), el error 429 puede aparecer por varias razones relacionadas con el uso de plugins, temas, peticiones externas o incluso ataques automatizados. Vamos a ver los casos más típicos y qué puedes hacer en cada uno.

Plugins que hacen demasiadas peticiones

Hay muchos plugins de WordPress que se conectan a servicios externos o realizan comprobaciones frecuentes (estoy pensando en los de SEO, los de seguridad, los de analítica, los que hacen backups automáticos, etc.).

Si tienes varios de estos plugins activos al mismo tiempo, es fácil que superes el límite de peticiones hacia una API externa o incluso hacia tu propio servidor, especialmente si están mal configurados y hacen llamadas constantes sin control.

¿Qué puedes hacer?

• Revisa los plugins que tienes activos y desactiva temporalmente los que no sean esenciales.
• Actualiza todos los que mantengas, porque las versiones más recientes suelen estar mejor optimizadas.
• Si puedes, escoge las alternativas más ligeras o que no dependan de llamadas externas constantes.
• También puedes limitar su frecuencia de ejecución desde la configuración o con ayuda de un plugin de optimización.

Problemas con bots o tráfico sospechoso

Los sitios que usan WordPress (y, sobre todo, las tiendas WooCommerce) a veces reciben ataques de bots que intentan hacer scraping de productos, dejar spam en formularios, realizar ataques de fuerza bruta… Todo esto genera muchísimas peticiones en poco tiempo, lo que puede disparar un error 429 si tienes algún sistema de protección activado.

¿Qué puedes hacer?

• Instala un plugin de seguridad como Wordfence, iThemes Security o Sucuri, que permiten limitar el número de intentos por IP y bloquear comportamientos sospechosos.
• Configura un firewall (ya sea desde un plugin o desde servicios como Cloudflare) para filtrar el tráfico más agresivo.
• Si usas WooCommerce, plantéate proteger las páginas más delicadas (como el login, el carrito o la pasarela de pago) con medidas como reCAPTCHA o retrasos entre intentos.

Peticiones desde servicios externos o integraciones

Si usas integraciones con otras plataformas (como CRMs, herramientas de email marketing, apps móviles o sistemas de gestión de pedidos), es posible que esas conexiones estén generando un número elevado de peticiones a tu servidor o a la API REST de WordPress, lo que también puede provocar un error 429.

¿Qué puedes hacer?

• Revisa el comportamiento de esas integraciones y ajusta su frecuencia (si tienes acceso al código, claro).
• Si el tráfico viene desde una aplicación de terceros, contacta con ellos para ver si pueden reducir la carga o espaciar más las llamadas.
• En algunos casos, puede estar bien implementar una autenticación más precisa (como tokens por usuario) o caché en las respuestas (si no cambian constantemente).

Límites de servicios como Cloudflare

Hay servicios de CDN o de seguridad (como Cloudflare) que aplican automáticamente límites de acceso si detectan un número excesivo de peticiones realizadas en poco tiempo.

¿Qué puedes hacer?

• Revisa si el error viene de Cloudflare (puedes verlo en los logs o mensajes de error). Si es así, puedes ajustar las reglas de rate limiting desde su panel.

Evita que el error 429 vuelva a frenar tu web

El error HTTP 429 no es de los más conocidos, pero cuando aparece puede dejar parte de tu sitio fuera de juego o generar una mala experiencia para tus usuarios o clientes. Por suerte, con un poco de análisis es relativamente fácil detectar su origen y aplicar una solución efectiva.

Como hemos visto, puede venir de muchos frentes: desde plugins que hacen demasiadas peticiones hasta integraciones mal optimizadas, bots que saturan el servidor o incluso límites impuestos por terceros. Lo importante es no quedarse solo con el mensaje de error 429, sino entender qué hay detrás.

¿El error 429 ha llamado a tu puerta? Pues ya sabes cómo cerrársela sin que te cueste visitas… ni quebraderos de cabeza.