El error HTTP 429 \u00abToo many requests\u00bb 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\u00e9cnico 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.<\/p>\n
El error 429 no es el c\u00f3digo HTTP<\/a> m\u00e1s 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\u00e1neamente. As\u00ed que no te asustes. Lo primero que hay que hacer es entender por qu\u00e9 se est\u00e1 produciendo y adaptar el comportamiento del cliente (o la configuraci\u00f3n del servidor) en consecuencia.<\/p>\n En este post, quiero explicarte qu\u00e9 significa exactamente el error 429, cu\u00e1les son sus causas m\u00e1s habituales, c\u00f3mo resolverlo en funci\u00f3n de su origen y qu\u00e9 hacer si el problema viene del uso de bots, scrapers o crawlers. En definitiva, quiero que tengas a mano una gu\u00eda completa para identificar bien el problema y aplicar la soluci\u00f3n adecuada, sin comerte mucho la olla.<\/p>\n Tabla de contenidos:<\/p> El error 429 \u00abToo many requests\u00bb aparece cuando un usuario o aplicaci\u00f3n realiza demasiadas peticiones a un servidor en un periodo de tiempo muy corto. Es una forma que tiene el servidor de protegerse y decir: \u201cEst\u00e1s haciendo demasiadas solicitudes, frena un poco\u201d.<\/p>\n Ver\u00e1s, hay un sistema llamado \u00abrate limiting\u00bb que sirve para poner l\u00edmites 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: \u201cSolo se puede hacer un m\u00e1ximo 100 peticiones por minuto por usuario\u201d. El objetivo es doble: proteger el rendimiento del servidor y garantizar un uso justo de los recursos para todos los usuarios.<\/p>\n \u00bfY qu\u00e9 pasa si se supera ese l\u00edmite? Pues que se devuelve el error 429 para forzar una pausa.<\/p>\n El error 429 \u00abToo many requests\u00bb se diferencia de otros errores HTTP en que no indica que haya un fallo del servidor ni un error en la solicitud. M\u00e1s bien es una respuesta que limita el n\u00famero de peticiones. \u00bfY para qu\u00e9? Pues su funci\u00f3n es proteger el sistema, ante todo.<\/p>\n A diferencia de errores como el error 404<\/a>, que indica que el recurso al que se quiere llegar no existe, o el error 500<\/a>, que suele indicar que hay un problema interno del servidor, el error 429 act\u00faa como mecanismo de control en un sistema que funciona perfectamente. \u00bfA qu\u00e9 me refiero? Pues a que el error 429 no indica que el servidor est\u00e9 roto, sino que sirve simplemente para marcar un l\u00edmite de forma temporal.<\/p>\n Adem\u00e1s, el error 429 tambi\u00e9n es distinto de errores como el 403 (que deniega el acceso en funci\u00f3n de los permisos) porque el 429 no proh\u00edbe el acceso de forma permanente. Tan solo le pide al cliente que espere un poco antes de volver a intentarlo.<\/p>\n \u00a1En resumen! El c\u00f3digo HTTP 429 no te est\u00e1 se\u00f1alando un error definitivo o que no se pueda subsanar, sino simplemente una situaci\u00f3n temporal provocada por un uso excesivo de los recursos. La clave est\u00e1 en modificar el ritmo de las peticiones y respetar los l\u00edmites que establece el sistema.<\/p>\n Pero vamos a ver algunas de las causas que nos pueden llevar a toparnos con el error 429. Despu\u00e9s, te ense\u00f1o las soluciones.<\/p>\n Vale, ya hemos quedado en que el error 429 indica que se ha alcanzado un l\u00edmite de peticiones impuesto para impedir que se haga un uso an\u00f3malo del servidor.<\/p>\n Ahora te estar\u00e1s preguntando qu\u00e9 causas pueden llevar a hacer saltar esa limitaci\u00f3n, \u00bfno? Pues vamos a verlas.<\/p>\n La pongo de primera porque es la causa m\u00e1s frecuente. El cliente (ya sea un navegador, una aplicaci\u00f3n m\u00f3vil, un script automatizado, etc.) est\u00e1 haciendo un n\u00famero 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\u00f3n y responde con un 429 para evitar una posible sobrecarga.<\/p>\n Como te digo, es una situaci\u00f3n com\u00fan en aplicaciones que realizan peticiones de forma continua o que no gestionan adecuadamente los intervalos entre llamadas a servicios externos.<\/p>\n Muchos servidores y APIs tienen marcados, de forma expl\u00edcita, unos l\u00edmites de uso para cada usuario, IP o aplicaci\u00f3n (es decir, para cada cliente). Estos l\u00edmites van a ser distintos en funci\u00f3n del proveedor o del servicio, e incluso seg\u00fan el tipo de cuenta o plan contratado.<\/p>\n Por ejemplo, imag\u00ednate 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\u00edmite. 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.<\/p>\n 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\u00f3n del servidor.<\/p>\n \u00bfCu\u00e1ndo es probable que suceda? Por ejemplo, cuando se hacen tareas de web scraping, pruebas automatizadas o tareas de monitorizaci\u00f3n intensivas. Muchos servidores detectan este tipo de actividad como potencialmente maliciosa y muestran el error 429 como mecanismo disuasorio.<\/p>\n Una causa menos evidente, pero igualmente importante, es la presencia de errores en el desarrollo del cliente. Por ejemplo, si una aplicaci\u00f3n tiene un bug que provoca que una misma petici\u00f3n se env\u00ede varias veces en bucle, puede superar r\u00e1pidamente los l\u00edmites establecidos por el servidor.<\/p>\n Tambi\u00e9n puede ocurrir en sistemas que no reutilizan correctamente datos en cach\u00e9 o que reintentan solicitudes fallidas de forma que acaban generando una alta carga de tr\u00e1fico innecesario.<\/p>\n Hay entornos (redes corporativas, instituciones educativas, conexiones mediante proxy…) en los que es habitual que haya varios usuarios compartiendo una \u00fanica direcci\u00f3n IP p\u00fablica. En estos casos, el servidor receptor puede interpretar todas las solicitudes como si provinieran del mismo cliente.<\/p>\n De este modo, aunque es posible que cada usuario est\u00e9 haciendo un uso razonable, si la suma total de las peticiones enviadas supera el l\u00edmite establecido para esa IP, puede aparecer un error 429 para todos los que la est\u00e9n utilizando.<\/p>\n Hay sistemas que est\u00e1n configurados para detectar patrones de tr\u00e1fico poco habituales, como un gran n\u00famero de accesos en muy poco tiempo desde la misma zona geogr\u00e1fica o direcci\u00f3n IP. Cuando se detecta que esto est\u00e1 sucediendo, es habitual que el servidor pase a aplicar medidas de protecci\u00f3n, como un bloqueo temporal mediante un error HTTP 429.<\/p>\n Y ojo, que esto no implica que se haya hecho necesariamente un mal uso intencionado, pero s\u00ed que ha habido un comportamiento que no es el que esperaba el sistema. Como resultado, el error 429\u00a0 se aplica de forma autom\u00e1tica como medida de seguridad.<\/p>\n Veamos. El error 429 no es un fallo del servidor, como tal, sino m\u00e1s bien una respuesta intencionada que indica que se ha superado un l\u00edmite. Por eso, la soluci\u00f3n depende en gran medida de qui\u00e9n est\u00e9 haciendo las peticiones y de c\u00f3mo est\u00e9 configurado el sistema.<\/p>\n \u00a1Por lo tanto!<\/p>\n Podemos decir que el error 429 se resuelve entendiendo su origen y ajustando el ritmo o la forma en que se hacen las peticiones.<\/p>\n Vamos a ver varios casos distintos para que veas a qu\u00e9 me refiero.<\/p>\n Si te est\u00e1 saliendo un error 429 y sospechas que viene de tu propia app o cliente, lo primero que tienes que hacer es mirar c\u00f3mo est\u00e1s haciendo las peticiones. Muchas veces el problema viene de ah\u00ed, de que est\u00e1s enviando demasiadas solicitudes seguidas sin darte cuenta.<\/p>\n Empieza por revisar el c\u00f3digo. Aseg\u00farate de que no tienes bucles que est\u00e9n lanzando llamadas de forma continua o haciendo reintentos sin control. A veces un fallo peque\u00f1o (un bucle Despu\u00e9s, ponle un poco de orden a las llamadas. Introducir un peque\u00f1o retraso entre peticiones (lo t\u00edpico: medio segundo, un segundo\u2026) puede venir genial si est\u00e1s rozando el l\u00edmite de uso de una API.<\/p>\n Tambi\u00e9n va bien usar lo que se llama \u00abretroceso exponencial\u00bb. En muy resumidas cuentas, si una petici\u00f3n 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\u00ed evitas insistir de m\u00e1s justo cuando el servidor ya te ha dicho que pares.<\/p>\n Y muy importante: si los datos que est\u00e1s pidiendo no cambian todo el rato, usa la cach\u00e9. Guarda la respuesta y reutil\u00edzala (si puedes), en lugar de hacer siempre la misma llamada. De este modo, no solo te evitas errores 429; adem\u00e1s, consigues que tu app funcione de forma m\u00e1s r\u00e1pida y eficiente.<\/p>\n Por \u00faltimo, si est\u00e1s usando una API externa, m\u00edrate la documentaci\u00f3n. Muchas veces, ah\u00ed te dicen el n\u00famero exacto de peticiones que puedes hacer por minuto o por hora.<\/p>\n Cuando usas una API de terceros, lo normal es que tenga un l\u00edmite de peticiones establecido, precisamente para evitar abusos.<\/p>\n Este tipo de restricciones suelen estar muy bien definidas por el propio proveedor, as\u00ed que lo primero que deber\u00edas hacer es consultar la documentaci\u00f3n oficial. Ah\u00ed suelen indicar cu\u00e1ntas peticiones puedes hacer por minuto, por hora o incluso por d\u00eda, seg\u00fan el plan que tengas contratado. Algunas APIs tambi\u00e9n te devuelven cabeceras como Si ves que te est\u00e1s quedando corto con esos l\u00edmites, una opci\u00f3n bastante directa es ver si puedes subir de plan. Muchas APIs tienen versiones gratuitas con restricciones ajustadas, pero ofrecen opciones de pago que ampl\u00edan esos m\u00e1rgenes. A veces, con solo cambiar a un plan b\u00e1sico de pago, ya puedes trabajar con m\u00e1s comodidad y sin tener que andar limitando tanto tus llamadas.<\/p>\n Otra alternativa \u00fatil 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\u00eda o del minuto, en funci\u00f3n de c\u00f3mo est\u00e9 estructurado el l\u00edmite.<\/p>\n Y si la API lo permite, podr\u00edas usar varias claves de autenticaci\u00f3n (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.<\/p>\n Es una situaci\u00f3n habitual en entornos como oficinas, centros educativos o redes en las que se accede a internet a trav\u00e9s de un proxy o cortafuegos com\u00fan.<\/p>\n En estos casos, aunque las peticiones provengan de diferentes usuarios, desde fuera todas parecen salir desde la misma direcci\u00f3n IP p\u00fablica. Como consecuencia, el servidor o la API que las recibe las interpreta como si fueran de un \u00fanico cliente\u2026 y devuelve un error 429 por exceso de peticiones.<\/p>\n Si crees que esto es lo que te est\u00e1 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\u00e1quinas usen diferentes IPs p\u00fablicas o incluso que salgan por distintos gateways para repartir el tr\u00e1fico. No siempre es viable, pero vale la pena revisarlo si el uso de la API es importante.<\/p>\n Tambi\u00e9n es buena idea que te pongas en contacto con el proveedor del servicio que te est\u00e1 devolviendo el error. Puedes explicarles que hay varios usuarios leg\u00edtimos trabajando desde una \u00fanica IP y pedirles que hagan una excepci\u00f3n o que ajusten el l\u00edmite a esa situaci\u00f3n. Muchas veces, si justificas bien el caso, est\u00e1n dispuestos a colaborar, sobre todo si se trata de un entorno profesional o educativo.<\/p>\n \u00bfY qu\u00e9 pasa si eres t\u00fa el que gestiona el servidor o la API que est\u00e1 lanzando el error 429? Pues que, al menos, tienes la ventaja de poder ajustar la configuraci\u00f3n de acuerdo con tus necesidades. En este caso, el problema suele estar en alguna pol\u00edtica de rate limiting<\/em> que t\u00fa mismo (o alguien de tu equipo) has configurado para proteger el sistema ante un exceso de peticiones.<\/p>\n Lo primero es revisar d\u00f3nde est\u00e1 aplicado ese l\u00edmite. Puede estar en varios niveles: en el servidor web (como Nginx o Apache), en el backend<\/a> de tu aplicaci\u00f3n (por ejemplo, si usas Express, Flask o Django) o incluso en servicios externos como un firewall o una CDN<\/a> (Cloudflare, por ejemplo, te permite configurar l\u00edmites de acceso). Cuando encuentres el punto correcto en el que est\u00e1 ese l\u00edmite, ya ser\u00e1s capaz de afinar con la soluci\u00f3n.<\/p>\n Entonces.<\/p>\n Una vez localizado, ajusta esos l\u00edmites teniendo en cuenta el comportamiento real de tus usuarios. No es lo mismo una API pensada para tr\u00e1fico ocasional que una que se va a usar de forma intensiva o en horarios muy concretos. Puedes ser m\u00e1s flexible con usuarios autenticados, definir distintos umbrales seg\u00fan el tipo de cuenta o la funcionalidad que est\u00e9n utilizando, etc.<\/p>\n Otro punto importante es que muchas veces se limita por IP por defecto, pero puede ser mucho m\u00e1s eficaz y justo aplicar los l\u00edmites por usuario autenticado, token de API o cualquier otro identificador \u00fanico. De este modo, no castigas a los usuarios que comparten una misma IP o que est\u00e1n usando un proxy.<\/p>\n Por \u00faltimo, no te olvides de ser lo m\u00e1s claro posible con los usuarios de tu sistema. Devu\u00e9lveles cabeceras como Cuando detr\u00e1s 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\u00e1pidas y, a veces, poco respetuosas con los l\u00edmites del sistema.<\/p>\n Si los bots los controlas t\u00fa (por ejemplo, porque est\u00e1s haciendo scraping de una web o recopilando datos desde una API) te tocar\u00e1 revisar bien su comportamiento. Aseg\u00farate de que est\u00e9n haciendo peticiones de forma gradual (es decir, con pausas razonables) e implementa un sistema de reintentos con retroceso exponencial.<\/p>\n Te lo contaba m\u00e1s 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\u2026 Y que cada vez que vuelva a fallar, se espere un poco m\u00e1s. De este modo, te evitas errores y reduces el riesgo de que te bloqueen por mal uso.<\/p>\n<\/blockquote>\n Si lo que est\u00e1s haciendo es acceder a un sitio externo, mira si tiene API p\u00fablica, 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\u00edmites m\u00e1s claros y datos m\u00e1s estructurados.<\/p>\nSignificado del c\u00f3digo 429 en HTTP<\/span><\/h2>\n
En qu\u00e9 se diferencia el error 429 de otros errores HTTP<\/span><\/h3>\n
Principales causas del error 429<\/span><\/h2>\n
1. Gran n\u00famero de peticiones en muy poco tiempo<\/span><\/h3>\n
2. L\u00edmite de uso configurado en el servidor (rate limiting)<\/span><\/h3>\n
3. Uso de bots, scrapers o automatizaciones<\/span><\/h3>\n
4. Errores en el c\u00f3digo del cliente<\/span><\/h3>\n
5. Varios usuarios que comparten una misma IP<\/span><\/h3>\n
6. Picos de tr\u00e1fico inesperados o comportamiento sospechoso<\/span><\/h3>\n
C\u00f3mo solucionar el c\u00f3digo HTTP 429 en funci\u00f3n del origen del problema<\/span><\/h2>\n
1. Si el problema est\u00e1 en el cliente o en la aplicaci\u00f3n que hace las peticiones<\/span><\/h3>\n
while<\/code> sin l\u00edmite o un reintento autom\u00e1tico sin condiciones) puede acabar mandando un mont\u00f3n de peticiones en segundos.<\/p>\n2. Si el l\u00edmite lo impone una API externa<\/span><\/h3>\n
Retry-After<\/code>, que te indican exactamente cu\u00e1nto debes esperar antes de volver a intentarlo.<\/p>\n3. Si hay varias personas compartiendo la misma direcci\u00f3n IP<\/span><\/h3>\n
4. Si el l\u00edmite est\u00e1 en tu propio servidor (y t\u00fa controlas el backend)<\/span><\/h3>\n
Retry-After<\/code> para que sepan cu\u00e1nto tienen que esperar antes de volver a intentarlo.<\/p>\n\u00bfY qu\u00e9 hago si el error 429 me lo est\u00e1n generando bots, scrapers o crawlers?<\/span><\/h2>\n
\n