Rate limit exceeded en Twitter: causas y arreglos (2026)

Por Sorsa Editorial

Actualizado el 11 de julio de 2026: precios de lectura por recurso vigentes de la API de X y el tope de 2 millones de lecturas de publicación verificados contra la documentación de precios de X, más los topes de lectura dentro de la app de 2026 ampliamente reportados para las cuentas gratis y Premium.

Conclusión clave: «Rate limit exceeded» en Twitter/X significa que hiciste más solicitudes de las que la ventana actual permite, así que la acción se bloquea brevemente. Los usuarios regulares lo disparan al desplazarse, refrescar, o seguir demasiado rápido; los desarrolladores ven un HTTP 429 con el código de error 88. El arreglo más rápido es detenerte y esperar a que la ventana se reinicie.

La frase «rate limit exceeded» apunta a dos problemas completamente diferentes, y el arreglo depende de cuál tengas. Si el mensaje apareció mientras te desplazabas o refrescabas la app, chocaste con un tope a nivel de plataforma en tu cuenta. Si apareció en un script o log de servidor como un HTTP 429, chocaste con el límite de tasa por endpoint de la API de X. Esta guía cubre ambos, empezando por cómo distinguirlos.

Para los desarrolladores, la razón por la que el mismo 429 sigue apareciendo a menudo es que tres límites separados lo devuelven todos: la ventana de 15 minutos por endpoint, los propios topes de tu cuenta de X, y un techo de uso mensual. Nosotros operamos Sorsa API, una API alternativa de Twitter/X, así que chocamos con estos límites y los 429 que producen todos los días, tanto en nuestros propios pipelines como a lo largo de las migraciones intensivas en lectura que manejamos. Por eso también construimos Sorsa sin el modelo de ventana: un límite fijo de 20 solicitudes por segundo en cada endpoint, sin reinicios de 15 minutos y sin una división por app versus por usuario que malabarear, con lecturas que salen mucho más baratas que el precio por recurso oficial. Los números de abajo son con los que estás trabajando en X ahora mismo, y más abajo ponemos los dos modelos lado a lado.

Última verificación: 11 de julio de 2026, contra la documentación de límites de tasa y de precios de X.

Tabla de contenidos

• Rate limit exceeded: el mensaje dentro de la app vs el 429 de la API
• Bloqueado mientras navegas X: causas y cuánto dura
• El 429 de la API de Twitter/X: estado HTTP y código de error 88
• ¿Qué límite chocaste? Las tres capas detrás de un 429
• El arreglo inmediato: lee el encabezado de reinicio y retírate
• Cómo evitar los límites de tasa de la API de Twitter
• ¿Un plan de pago quita el límite de tasa?
• En la práctica: un equipo de escucha social que se seguía atascando en 429s
• Preguntas frecuentes

Rate limit exceeded: el mensaje dentro de la app vs el 429 de la API {#rate-limit-exceeded-the-in-app-message-vs-the-api-429}

Las mismas tres palabras describen dos fallas no relacionadas. Una es un bloqueo de plataforma en una cuenta de X normal, mostrado en la app o en el sitio web. La otra es un HTTP 429 devuelto a un programa que llama a la API de X. Tienen causas diferentes, comportamiento de reinicio diferente, y arreglos diferentes, así que el primer paso es emparejar tu síntoma con la columna correcta.

Si eres un usuario regular y nunca tocas la API de desarrollador, solo las primeras dos filas te corresponden, y el arreglo casi siempre es detenerte y esperar. Si estás construyendo contra la API, el 429 es una señal que puedes leer y responder en código, que es donde se enfoca la mayor parte de esta guía. Los dos sistemas se hacen cumplir por separado: una cuenta normal y una app de desarrollador toman de presupuestos diferentes, así que estar bien en uno no te protege en el otro.

Bloqueado mientras navegas X: causas y cuánto dura {#blocked-while-browsing-x-causes-and-how-long-it-lasts}

Si el mensaje apareció mientras usabas X con normalidad, cruzaste un tope a nivel de plataforma atado a tu cuenta, no un límite de API. X aplica estos topes a leer, publicar, seguir, dar like, y mensajear para frenar la automatización y proteger su infraestructura. El bloqueo es temporal y se despeja por su cuenta una vez que la ventana se reinicia.

El disparador más común para los usuarios regulares es el tope de lectura diario introducido en julio de 2023 y todavía activo, en forma relajada, en 2026. X no publica oficialmente los números exactos, pero las cifras reportadas consistentemente a lo largo de pruebas de cuentas son aproximadamente 1,000 publicaciones al día para las cuentas gratis no verificadas, alrededor de 10,000 para las cuentas Premium verificadas, y unas 500 para las cuentas nuevas no verificadas de menos de un mes. Cada publicación que se desplaza cuenta como una lectura, incluso las que no tocas, así que el desplazamiento pesado a través de un feed rico en multimedia es lo que usualmente lo dispara.

Otras acciones de cuenta tienen sus propios topes. Seguir y dejar de seguir demasiado rápido (aproximadamente unas pocas docenas por hora es donde empiezan los problemas), dar like disparado rápido, enviar muchos mensajes directos, o cambiar el correo de tu cuenta más de un puñado de veces por hora pueden producir cada uno el mismo mensaje. Las apps de terceros conectadas a tu cuenta hacen llamadas a la API en segundo plano y toman de tu presupuesto también, así que un programador, una herramienta de analítica, y un rastreador de seguidores corriendo a la vez pueden drenarlo sin ninguna acción de tu parte.

Cuánto dura depende de qué tope chocaste:

• La mayoría de los bloqueos basados en ventana se despejan en 15 a 60 minutos una vez que la ventana deslizante pasa.
• Los topes diarios, incluido el límite de lectura, se reinician a la medianoche UTC.
• Las violaciones repetidas pueden extender las restricciones a 24 a 72 horas en las cuentas marcadas.

Los arreglos son simples y sobre todo se tratan de esperar de forma limpia. Deja de refrescar, porque cada reintento puede extender el enfriamiento. Cierra la app o la pestaña y aléjate por media hora. Si usas clientes de terceros, cierra sesión de todos ellos, ya que sus llamadas en segundo plano pueden ser la causa real. Revisa Downdetector o las actualizaciones de estado propias de X en caso de que un incidente en toda la plataforma esté siendo mal reportado como un límite de tasa. Si el bloqueo persiste por horas, cerrar sesión, limpiar cookies, y volver a iniciar sesión a veces ayuda. Para el desglose completo de los topes a nivel de cuenta por acción y tipo de cuenta, nuestra referencia sobre los límites de tasa de cuenta y de API de X lista cada uno con números vigentes.

El 429 de la API de Twitter/X: estado HTTP y código de error 88 {#the-twitterx-api-429-http-status-and-error-code-88}

En la API de desarrollador, «rate limit exceeded» llega como una respuesta HTTP 429. Significa que enviaste más solicitudes a un endpoint de las que su límite permite dentro de la ventana actual, así que la siguiente llamada se rechaza hasta que la ventana se reinicia. El 429 es la señal a nivel de transporte; X también devuelve un identificador a nivel de aplicación en el cuerpo de la respuesta.

La forma exacta depende de qué cliente y versión de API estés llamando, pero todos estos describen el mismo evento:

• Línea de estado simple: HTTP 429 Too Many Requests.
• Cuerpo estilo X v1.1: {"errors":[{"code":88,"message":"Rate limit exceeded"}]}, donde el código 88 es el identificador canónico de X para este error.
• Cuerpo estilo X v2: {"title":"Too Many Requests","detail":"Too Many Requests","type":"about:blank","status":429}.
• Tweepy: lanza tweepy.errors.TooManyRequests, que un manejador de excepciones genérico alrededor de tus llamadas atrapará.
• Detrás de tu propia app: el front end a menudo reemplaza el 429 crudo con un mensaje genérico de «cannot load», así que el error real solo se muestra en los logs de tu servidor.

Una vez que has confirmado un estado 429 o el código 88, el empaquetado no importa y aplican los mismos arreglos. Lo que sí importa es averiguar qué límite cruzaste realmente, porque en la API de X actual tres límites diferentes pueden devolver cada uno un 429, y el arreglo es diferente para cada uno. Si el error se dispara específicamente durante un flujo de inicio de sesión en lugar de durante las lecturas, puede que no sea un límite de tasa en absoluto sino una revisión anti-automatización; lo cubrimos por separado en nuestra guía sobre el mensaje «this request looks like it might be automated».

¿Qué límite chocaste? Las tres capas detrás de un 429 {#which-limit-did-you-hit-the-three-layers-behind-a-429}

Un solo 429 en la API de X puede venir de tres sistemas separados, y «no estoy para nada cerca de mi límite de tasa» es una queja tan común porque la gente revisa una capa y se pierde las otras dos. Leer los encabezados de respuesta te dice cuál te detuvo.

Capa 1: el límite de tasa por endpoint. Cada endpoint de la API de X v2 tiene su propio tope en una ventana deslizante de 15 minutos (unos pocos usan ventanas de 24 horas), rastreado en dos pools independientes: un límite por app para la autenticación con Bearer Token y un límite por usuario para los tokens de usuario OAuth. La búsqueda reciente, por ejemplo, permite 300 solicitudes por 15 minutos por usuario. Diez mil usuarios golpeando un backend solo-de-app gastan todos de un pool por app compartido, así que una app puede ser estrangulada incluso cuando ningún usuario individual está por encima de su límite personal. Esta es la capa que describen los encabezados x-rate-limit-*.

Capa 2: los propios topes de tu cuenta de X. Separados de los límites de la API de desarrollador, la cuenta de X detrás de tu app está atada por los topes a nivel de plataforma que cuentan las acciones de la web, el celular, y la API juntas. Una automatización que publica a través de la API toma del mismo presupuesto diario que las publicaciones manuales desde un teléfono. Si tu flujo de trabajo actúa sobre una cuenta en lugar de solo leer datos públicos, un tope de cuenta puede producir un 429 mientras tu presupuesto por endpoint todavía muestra espacio.

Capa 3: el tope de uso mensual. Desde que X pasó al precio de pago por uso en 2026, las cuentas estándar cargan un techo duro de 2 millones de lecturas de publicación al mes. Puedes sentarte cómodamente dentro de cada ventana de 15 minutos y aun así quedar bloqueado porque el tope mensual está gastado. Los límites de tasa controlan qué tan rápido llamas; el tope de uso controla cuánto consumes por ciclo de facturación. Se rastrean y se hacen cumplir por separado.

Aquí está cómo distinguirlos en unos segundos:

Para el trabajo intensivo en lectura, el tope mensual es usualmente lo que chocas primero, no el límite de tasa. La ventana por endpoint se vuelve el verdadero cuello de botella principalmente para las escrituras y para los pipelines de alta concurrencia en la autenticación solo-de-app. Los números completos por endpoint, pool por pool, viven en nuestra referencia de límites de tasa de la API de X, y el lado de costo del tope de 2 millones está en nuestro desglose de precios de la API de X.

El arreglo inmediato: lee el encabezado de reinicio y retírate {#the-immediate-fix-read-the-reset-header-and-back-off}

La forma más rápida de salir de un límite de tasa de la Capa 1 es esperar exactamente lo que la ventana necesita, no un intervalo fijo a ciegas. Cada respuesta de la API de X, incluido el 429 mismo, carga tres encabezados que te dicen dónde estás parado:

x-rate-limit-limit: 900
x-rate-limit-remaining: 12
x-rate-limit-reset: 1783779300

x-rate-limit-limit es el techo para la ventana actual. x-rate-limit-remaining es lo que te queda. x-rate-limit-reset es una marca de tiempo Unix de cuándo la ventana se reabre. Resta la hora actual de esa marca de tiempo y sabes precisamente cuántos segundos esperar. No hay ninguna adivinanza involucrada.

La recuperación ingenua duerme unos 15 minutos fijos y reintenta. Funciona pero desperdicia tiempo. Un patrón mejor lee la marca de tiempo de reinicio, espera solo eso, y recurre al backoff exponencial si el encabezado falta:

import time
import requests

def request_with_backoff(url, headers, params=None, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, params=params, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response

        reset = response.headers.get("x-rate-limit-reset")
        if reset:
            wait = max(int(reset) - int(time.time()), 1)
        else:
            wait = delay          # no header: exponential backoff
            delay *= 2
        print(f"429 hit, waiting {wait}s (attempt {attempt + 1}/{max_retries})")
        time.sleep(wait + 1)      # small buffer past the reset

    raise RuntimeError("Rate limit retries exhausted")

Dos reglas importan más que el código. No reintentes al instante, porque un bucle de reintento apretado quema tu presupuesto restante a lo largo de otros endpoints (en la autenticación solo-de-app) y puede disparar un estrangulamiento más pesado. Y no ignores los 429 en los pipelines masivos: un 429 en un bucle de recolección puede significar cientos de solicitudes fallidas antes de que tu código reaccione, así que revisa x-rate-limit-remaining antes de cada llamada y pausa cuando caiga por debajo de aproximadamente el 10 a 20 por ciento del límite. Un log de serie de tiempo de x-rate-limit-remaining es el artefacto individual más útil cuando estás depurando qué patrón de llamadas drena el presupuesto.

Cómo evitar los límites de tasa de la API de Twitter {#how-to-avoid-twitter-api-rate-limits}

El backoff te saca de la ventana actual. Mantenerte lejos del muro se trata de gastar menos solicitudes por unidad de dato. Estos son los movimientos que de verdad cambian las cuentas, sacados de las migraciones de pipeline de lectura que maneja nuestro equipo.

Haz lotes en lugar de iterar consultas individuales. El endpoint de tweets por lotes de X toma hasta 100 IDs de tweet en una llamada, y su endpoint de usuario hasta 100 usuarios o IDs, cada uno una solicitud contra un límite por lotes más alto en lugar de 100 golpes separados de uno más ajustado. Las APIs de terceros empujan esto más lejos: nuestro endpoint de tweets por lotes toma 100 URLs o IDs de tweet por solicitud y nuestra consulta de perfiles por lotes toma 100 perfiles, cada una contando como una sola solicitud de tu cuota.

Cachea los datos de movimiento lento. Los metadatos de perfil, los conteos de seguidores, y las resoluciones de usuario-a-ID cambian a lo largo de días, no de segundos. Cachéalos con un TTL de 12 a 24 horas y sáltate la llamada ante un acierto de caché. Las métricas de engagement se mueven más rápido, así que un TTL de 1 a 6 horas es un balance razonable para la analítica.

Pagina con cursores, no vuelvas a obtener. Usa el cursor de respuesta para obtener la siguiente página en lugar de volver a correr la consulta original. Volver a correr busca el mismo contenido que ya pagaste.

Cambia el sondeo por streaming donde puedas. Sondear la búsqueda reciente cada 30 segundos son 2,880 solicitudes al día contra un endpoint. El filtered stream de X empuja las publicaciones que coinciden sobre una sola conexión persistente en su lugar. Para los proveedores sin streaming, el sondeo rápido sobre un límite fijo por segundo cubre la mayoría de las necesidades en tiempo real; profundizamos en las contrapartidas en nuestra guía de monitoreo de Twitter en tiempo real.

Reparte entre pools de auth. Los límites por app y por usuario son independientes, así que autenticarte con tanto un Bearer Token como un token de usuario OAuth te da dos baldes en los endpoints que admiten ambos. Esto ayuda solo del lado del servidor y usualmente es imposible en una app solo-de-cliente.

El arreglo estructural, si sigues chocando con el muro en el trabajo intensivo en lectura, es moverte fuera del modelo de ventana por completo. Un límite de tasa fijo quita el reinicio de 15 minutos y la división por app versus por usuario que causan la mayoría de los 429 en los pipelines de recolección. Sorsa sirve los 40 de sus endpoints de lectura a 20 solicitudes por segundo en todos los planes, y el límite se puede subir para casos de uso de alto volumen a través de habla con ventas.

¿Un plan de pago quita el límite de tasa? {#does-a-paid-plan-remove-the-rate-limit}

No. En la API oficial de X, subir de plan sube el techo; no lo quita. Cada nivel todavía estrangula por endpoint, y los contratos Enterprise (históricamente desde alrededor de $42,000 al mes) negocian ventanas más altas y topes de uso levantados en lugar de un camino ilimitado. No hay un plan autoservicio que quite el límite de tasa en X.

Existen dos rutas estructurales si sigues chocando con el muro en las lecturas. Una es pagarle a X más por un techo más alto, lo que aún te deja dentro del modelo de ventana y del tope mensual de 2 millones de lecturas de publicación. La otra es leer datos públicos de X a través de una API de terceros que no está construida sobre ventanas fijas, así que el costo escala con lo que extraes en lugar de con un precipicio de reinicio duro. Para una comparación completa del campo, consulta nuestro repaso de alternativas a la API de Twitter.

Para las cargas de lectura en específico, los dos modelos se alinean así:

Una solicitud de Sorsa devuelve hasta 100 tweets o hasta 200 perfiles, que es de donde vienen las cifras por cada 1,000. En la recolección intensiva en lectura eso sale en hasta 50 veces más barato por lectura que el precio por recurso oficial, y las ventanas de 15 minutos desaparecen por completo. La contrapartida honesta es que Sorsa es de solo lectura: cualquier cosa que publique, envíe DMs o dé like todavía pasa por la API oficial, porque ese es el camino en cumplimiento para las escrituras. El patrón común que vemos es mantener las escrituras en X y mover la lectura pesada a un proveedor de tarifa plana, que nuestra guía de migración recorre.

Otras APIs de terceros también quitan el tope de ventana de X, pero la mayoría son de pago por uso medido en lugar de tarifa plana. TwitterAPI.io, por ejemplo, cobra aproximadamente $0.15 por cada 1,000 tweets y unos $0.18 por cada 1,000 perfiles (revisado en julio de 2026). El precio medido mata el 429 de ventana fija, pero la factura todavía escala con el volumen y no está fija de antemano. Los planes de tarifa plana de Sorsa mantienen el costo mensual predecible y aterrizan más baratos por lectura, desde $0.02 por cada 1,000 tweets en los endpoints por lotes.

En la práctica: un equipo de escucha social que se seguía atascando en 429s {#in-practice-a-social-listening-team-that-kept-stalling-on-429s}

Una herramienta de escucha social de tamaño medio (aproximadamente una docena de ingenieros) llegó a nosotros después de que su recolección de X se siguiera atascando a mitad de la corrida. Estaban sondeando la búsqueda reciente en un bucle apretado para atrapar las menciones de marca de sus propios clientes, luego abriéndose en abanico a consultas de perfil por autor, y no podían descifrar por qué un límite de «300 por 15 minutos» seguía produciendo 429s. La causa era la usual: la autenticación solo-de-app significaba que cada búsqueda y cada consulta de perfil tomaban del mismo pool por app, y la cadencia de sondeo por sí sola estaba gastando la mayor parte antes de que el abanico siquiera empezara.

No los movimos fuera de la API oficial para nada que escribieran; movimos la recolección intensiva en lectura a un modelo de tarifa plana y cambiamos el sondeo por recolección impulsada por eventos. En el precio por recurso, ese volumen de lectura se sentaba en la incómoda zona entre el pago por uso barato y un contrato Enterprise de $42,000. Su factura de lectura cayó en más de un 90 por ciento, y los 429s desaparecieron una vez que las ventanas de 15 minutos y la división por app versus por usuario quedaron fuera del panorama. El tipo de rastreo continuo de menciones de marca que corren es exactamente para lo que está construida nuestra solución de escucha social.

Preguntas frecuentes {#faq}

¿Por qué Twitter dice «rate limit exceeded»?

Twitter/X muestra «rate limit exceeded» cuando haces más solicitudes de las que un tope permite dentro de una ventana de tiempo fija, así que bloquea la acción hasta que la ventana se reinicia. Para los usuarios regulares el disparador usualmente es leer, desplazarse, seguir, o dar like demasiado rápido. Para los desarrolladores es un HTTP 429 de la API, donde se cruzó el límite por ventana de un endpoint, un tope de cuenta, o el techo de uso mensual.

¿Cuánto dura un límite de tasa de Twitter?

La mayoría de los límites de tasa de Twitter/X son cortos. Los bloqueos dentro de la app por desplazamiento o acciones rápidas típicamente se despejan en 15 a 60 minutos una vez que la ventana deslizante pasa, y los topes diarios se reinician a la medianoche UTC. En la API, el tiempo de reinicio exacto está en el encabezado de respuesta x-rate-limit-reset como una marca de tiempo Unix, usualmente a 15 minutos. Las violaciones repetidas en una cuenta pueden extender las restricciones a 24 a 72 horas.

¿Cómo evitas los límites de tasa de la API de Twitter?

Gasta menos solicitudes por unidad de dato. Usa endpoints por lotes que devuelven hasta 100 ítems en una llamada en lugar de iterar consultas individuales, cachea los datos de movimiento lento como los perfiles por horas, pagina con cursores en lugar de volver a correr consultas, y prefiere el streaming o el sondeo rápido sobre los bucles de sondeo apretados. El arreglo estructural para el trabajo intensivo en lectura es un límite de tasa fijo por segundo en lugar de las ventanas de 15 minutos de X.

¿Un plan de pago quita el límite de tasa de Twitter?

No. Subir de plan en la API oficial de X sube el techo pero nunca quita el límite de tasa, y cada nivel incluido Enterprise todavía estrangula por endpoint bajo un tope mensual de 2 millones de lecturas de publicación. Una alternativa de solo lectura como Sorsa API reemplaza el modelo de ventana con 20 solicitudes por segundo en todos los planes, desde $0.02 por cada 1,000 tweets en los endpoints por lotes, lo que quita el 429 en lugar de subirlo.

¿El límite de tasa de la API de X es por usuario o por app?

Ambos, según el endpoint y tu autenticación. La autenticación con Bearer Token usa límites por app, donde cada solicitud de tu aplicación comparte un pool, así que una app puede ser estrangulada incluso cuando ningún usuario individual está por encima de su límite. La autenticación con token de usuario OAuth usa límites por usuario, donde cada usuario autenticado obtiene un balde independiente. Muchos endpoints publican ambas cifras.

¿Por qué tengo límite de tasa cuando apenas he hecho solicitudes?

Usualmente una de tres cosas. El tope es por app además de por usuario, así que tus usuarios colectivamente están por encima del límite de toda la app. O el endpoint que llamaste tiene un límite más ajustado del que esperas, así que revisa ese número específico en lugar de una cifra principal. O un proceso en segundo plano, un script olvidado, o tu tope de uso mensual es la causa real. Registrar x-rate-limit-remaining en cada llamada lo hace visible.

Cómo empezar

Si los 429s y las ventanas de 15 minutos de arriba son el problema del que estás tratando de salir, la forma más rápida de sentir la diferencia es correr unas cuantas llamadas tú mismo. Nuestro playground interactivo ejecuta endpoints en vivo en el navegador sin clave y sin registro, así que puedes revisar la forma de la respuesta antes de comprometerte con nada. Cuando estés listo para construir, el quickstart de Sorsa API te autentica con una sola clave API en un encabezado, y cada cuenta nueva empieza con 100 solicitudes gratis: por única vez, sin tarjeta de crédito, sin vencimiento y válidas en los 40 endpoints, suficiente para hasta 10,000 tweets o 20,000 perfiles a través de los endpoints por lotes. Pasado eso, el precio parte de $0.02 por cada 1,000 tweets en los endpoints por lotes, con planes desde $49 al mes a las 20 solicitudes por segundo. Sin revisión de app, sin pasar por OAuth y sin tablas de límite de tasa que mantener en la cabeza.

Revisado por Keksich, fundador de Sorsa, especialista en marketing e investigador de la API de X.

Cómo se armó esta guía: el formato del 429, los encabezados x-rate-limit-*, y el comportamiento de la ventana por endpoint se verificaron contra la documentación oficial de límites de tasa de X, y los topes de lectura dentro de la app contra la guía de límites publicada de X y las pruebas de cuentas vigentes, todo el 11 de julio de 2026, porque estos números cambian sin mucho aviso. El diagnóstico de tres capas, el código de recuperación consciente del reinicio, y el encuadre de rendimiento vienen de nuestro propio trabajo operando una API alternativa de Twitter/X y las migraciones de pipeline de lectura que maneja nuestro equipo, incluido el caso de escucha social anonimizado de arriba (detalles fusionados y despojados de cualquier cosa identificable). Las cifras de precio y de tope de uso están resumidas de nuestra cobertura separada de precios de la API de X; los precios de competidores se revisaron en la fuente en julio de 2026. Para saber quiénes somos y cómo contactarnos, consulta Acerca de Sorsa. Ninguna estadística, fuente ni resultado de cliente aquí es inventado.