Límites de tasa de la API de Twitter (rate limits) en 2026

Por Sorsa Editorial

Actualizado en julio de 2026: reconstruida como referencia completa que cubre todas las categorías de endpoints de la API de X v2 (unos 100 endpoints, re-verificados contra las tablas oficiales de límites de tasa de X a finales de julio de 2026). Agrega los límites de multimedia, marcadores, Spaces, tendencias, streaming y webhooks, amplía la sección del nivel gratuito y mantiene al día el cambio a solo Enterprise de abril de 2026 y el recorte de topes de cuenta de mayo de 2026.

Conclusión clave: Los límites de tasa de la API de X v2 se aplican por endpoint, se dividen en pools por app (Bearer Token) y por usuario (OAuth), y se reinician en ventanas de 15 minutos o de 24 horas. La búsqueda reciente permite 300 solicitudes por cada 15 minutos por usuario; publicar, 100. Exceder cualquier límite devuelve HTTP 429, y el encabezado x-rate-limit-reset indica exactamente cuándo se reabre la ventana.

En realidad hay tres sistemas distintos que pueden detener tus solicitudes, y los tres devuelven errores que se parecen entre sí. Tu app de desarrollador está sujeta a los límites de tasa por endpoint de la API de X. La cuenta de X desde la que publica está sujeta a topes separados a nivel de cuenta, hoy tan bajos como 50 posts al día para cuentas no verificadas. Y un saldo de pago por uso está sujeto a un tope de uso mensual de 2 millones de lecturas de posts por encima de los dos anteriores. Chocar con cualquiera de los tres te frena en seco, y por eso "no estoy ni cerca de mi límite de tasa" es una queja tan común y tan confusa.

Esta guía recorre las tres capas con números vigentes, empezando por las tablas completas por endpoint. Operamos Sorsa API, una API alternativa de Twitter/X, así que chocamos con estos límites y con los 429 que producen todos los días, tanto en nuestros propios pipelines como en las migraciones que manejamos. Esa es también la razón por la que construimos Sorsa sin ellos: el mismo límite de 20 solicitudes por segundo (20 req/s) en todos los planes y en todos los endpoints, sin ventanas de 15 minutos ni división por app contra por usuario que hacer malabares, y lecturas desde $0.02 por cada 1,000 tweets en los endpoints por lotes frente a $5.00 por cada 1,000 lecturas de posts en el pago por uso oficial, con 100 solicitudes gratis al registrarte para probarlo. Los números de abajo son con los que trabajas hoy en la API oficial de X, y más abajo ponemos los dos modelos lado a lado.

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

Los límites que más se consultan

Si llegaste aquí por un solo número, lo más probable es que esté en esta tabla. Todo lo demás se cubre a detalle más abajo.

Contenido

• Cómo funcionan los límites de tasa de la API de X
• Tablas de límites de tasa de la API de X: todos los endpoints
• Límites de publicación de la API de X: topes de API vs topes de cuenta
• Límites del nivel gratuito de la API de X en 2026
• ¿Cuántos tweets puedes extraer de verdad por día?
• Límites de tasa estándar vs Enterprise
• Qué pasa cuando chocas con un límite de tasa (429)
• Cómo mantenerte por debajo de los límites de tasa
• Preguntas frecuentes

Cómo funcionan los límites de tasa de la API de X {#how-x-api-rate-limits-work}

Los límites de tasa de la API de X v2 se fijan por endpoint, sin un único número global. La mayoría de los endpoints se reinician en una ventana deslizante de 15 minutos; algunos, como publicar y subir multimedia, usan ventanas de 24 horas, y unos cuantos endpoints de streaming y de archivo agregan un tope por segundo. La ventana empieza en tu primera solicitud a ese endpoint, no en una hora de reloj fija, así que "300 por cada 15 minutos" significa 300 solicitudes en cualquier lapso deslizante de 15 minutos.

Límites por app vs por usuario

Cada endpoint rastrea hasta dos pools independientes:

Los límites por app se aplican cuando te autenticas con un Bearer Token (autenticación de solo app). Cada solicitud que hace tu aplicación sale de un mismo pool compartido, sin importar cuál de tus usuarios la disparó. Diez mil usuarios golpeando el backend a la vez gastan todos del mismo cubo por app.

Los límites por usuario se aplican cuando te autenticas con tokens de usuario OAuth 1.0a u OAuth 2.0. Cada usuario autenticado obtiene un cubo aparte. Con 100 usuarios, cada uno tiene sus propias 300 solicitudes de búsqueda reciente por cada 15 minutos.

Unos endpoints exponen los dos pools, otros solo uno. En las tablas de abajo, "n/a" significa que ese tipo de autenticación no está disponible para esa llamada.

Cómo leer tus límites en los encabezados de la respuesta

Cada respuesta de la API de X lleva tres encabezados que te dicen exactamente en qué punto estás:

x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800

x-rate-limit-limit es el techo de la ventana actual. x-rate-limit-remaining es lo que queda. x-rate-limit-reset es una marca de tiempo Unix del momento en que se reinicia la ventana. Parsea esa marca, réstale la hora actual y sabes con precisión cuántos segundos esperar. Nunca tienes que adivinar.

Límites de tasa vs topes de uso vs límites de cuenta

Esta distinción hace tropezar a más desarrolladores que cualquier cifra concreta, así que aquí están las tres capas lado a lado:

Desde que X pasó al precio de pago por uso a principios de 2026, cada recurso que traes cuesta dinero, y las cuentas estándar cargan el tope mensual duro de 2 millones de lecturas de posts. Puedes estar cómodamente dentro de tu límite de tasa de 15 minutos y aun así quedar bloqueado porque quemaste el tope mensual. Para el lado del costo (precios por acción, la ventana de deduplicación de 24 horas y qué cambió el 20 de abril de 2026), consulta nuestro desglose de precios de la API de X.

Una aclaración más: si eres un usuario común de X y ves el error "Rate limit exceeded" (límite de velocidad superado) mientras navegas o publicas desde la app, eso es el tope del lado de la plataforma, no la API de desarrollador. Lo tratamos aparte en qué significa "Rate limit exceeded" en X y cómo solucionarlo. Todo lo de abajo es para quienes llaman a la API.

Tablas de límites de tasa de la API de X: todos los endpoints {#x-api-rate-limit-tables-every-endpoint}

La documentación oficial de X lista hoy unos 100 endpoints repartidos en más de una docena de categorías. Las tablas de abajo los cubren todos, agrupados por lo que intentas hacer y no por la taxonomía interna de producto de X. Todas las cifras se leyeron de las tablas oficiales de límites de tasa de X y se verificaron de nuevo el 31 de julio de 2026. Los límites son por cada 15 minutos salvo que se indique otra cosa.

Límites de búsqueda y consulta de tweets

La búsqueda merece una mirada más de cerca porque se divide en dos endpoints con techos muy distintos. La búsqueda reciente da 300 solicitudes por cada 15 minutos por usuario, pero solo alcanza 7 días hacia atrás, lo que cubre la mayoría de las búsquedas de tweets que se hacen por la API. La búsqueda de archivo completo se remonta a 2006, pero te topa en 1 solicitud por segundo, así que no puedes hacer ráfagas. Si necesitas profundidad histórica, ese tope duro de 1/seg es el número con el que tienes que planear; cubrimos cómo trabajar dentro de él en nuestra guía para extraer datos históricos de Twitter.

Límites de cronologías y menciones

Límites de publicación, borrado y multimedia

Las dos cifras que importan para la mayoría de las automatizaciones de publicación: 100 posts por cada 15 minutos por usuario y 50 borrados por cada 15 minutos por usuario. Ambas son techos del lado de la API; los topes a nivel de cuenta de más abajo suelen apretar antes.

Límites de consulta de engagement (likes, retweets y citas)

Todas las consultas de engagement quedan en un uniforme 75 por cada 15 minutos, uno de los techos de lectura más ajustados de la API. Auditar quiénes hicieron retweet o dieron like a un post viral lo agota rápido.

Límites de escritura de engagement (solo Enterprise desde abril de 2026)

A partir del 20 de abril de 2026, X quitó los follows, los likes y los posts citados de todos los niveles de autoservicio. Los límites de arriba siguen en las tablas de X, pero ahora solo se aplican bajo un contrato Enterprise. Publicar y los mensajes directos siguen disponibles en pago por uso.

Límites de consulta de usuarios y seguidores

Los endpoints de seguidores y de seguidos comparten un mismo límite de 300 por cada 15 minutos en los dos pools. A 1,000 resultados por página, paginar una cuenta de un millón de seguidores toma de 16 a 17 ventanas, unas cuatro horas de tiempo real. Si extraer listas de seguidores y seguidos a escala es tu carga central, ese ritmo es la restricción con la que tienes que diseñar.

Límites de mensajes directos

A 15 lecturas por cada 15 minutos por usuario, los flujos de trabajo con muchos DMs chocan con su techo casi de inmediato; los topes de envío por cada 24 horas hacen que la automatización aquí sea deliberadamente lenta por diseño.

Límites de listas

Los tweets de una lista y los miembros de una lista, a 900 por cada 15 minutos, están entre los límites de lectura más generosos de la API, y por eso las listas siguen siendo un rodeo popular para monitorear.

Límites de Spaces, tendencias, Comunidades, analítica y noticias

Límites de marcadores, bloqueos y silenciados

Límites de streaming y webhooks

Los endpoints de streaming son de solo app. El modelo mental que importa: el límite rige los intentos de conexión y los cambios de reglas, no el volumen entregado, y por eso una sola conexión de stream sana le gana a cualquier bucle de sondeo.

Límites de cumplimiento y uso

Límites de publicación de la API de X: topes de API vs topes de cuenta {#x-api-posting-rate-limits-api-caps-vs-account-caps}

X aplica la publicación en dos capas separadas en 2026, y la capa de la API casi nunca es la que te detiene.

El endpoint de escritura de la API (/2/tweets) permite 100 posts por cada 15 minutos por usuario y 10,000 por cada 24 horas por app. Aparte, la cuenta de X desde la que publicas está atada a topes a nivel de cuenta que se aplican por igual en web, celular y API. En mayo de 2026 ese tope de cuenta bajó a 50 posts originales y 200 respuestas al día para las cuentas no verificadas, desde los longevos 2,400.

Esta es la trampa. Quienes desarrollan leen el límite de la API (100 por cada 15 minutos se ve generoso, casi 9,600 al día por usuario), diseñan la arquitectura alrededor de él y luego el bot se detiene a los 50 posts. El límite de la API nunca fue la restricción vinculante:

• Cuenta no verificada + automatización por API: el tope de cuenta de 50 posts originales al día llega mucho antes de que la ventana de la API importe. Las respuestas se topan aparte en 200 al día, y se reporta ampliamente que los reposts y las citas cuentan hacia esos 50, aunque X no lo ha declarado de plano.
• Cuenta verificada o Premium + automatización por API: el tope a nivel de cuenta es más alto (X no publica la cifra exacta), así que el límite de escritura de la API pasa a ser el techo real.
• Escala a nivel de app: incluso con muchos usuarios verificados, 10,000 posts por cada 24 horas por app es un muro infranqueable para publicar a alto volumen.

La documentación de límites de cuenta de X es explícita en que estos topes cuentan las acciones de todos los dispositivos, web, celular y API juntos, así que tu script y tu teléfono comparten el mismo presupuesto diario de posts. Los topes a nivel de cuenta que más se automatizan:

Para el panorama completo del lado de la cuenta, incluidos los techos del nivel verificado, los subintervalos de media hora y qué cambió en mayo de 2026, consulta nuestra guía dedicada a los límites de publicación de X y los topes diarios de posts.

Publicar es también la única área con la que ninguna alternativa de solo lectura puede ayudarte. Proveedores como Sorsa están construidos para leer datos de X a escala, no para escribir en ella, así que si tu trabajo es publicar de forma automática, los endpoints de escritura de la API oficial son inevitables y estos son los límites con los que vives.

Límites del nivel gratuito de la API de X en 2026 {#x-api-free-tier-limits-in-2026}

No hay un nivel gratuito general de la API de X para nuevos desarrolladores en 2026. El nivel gratuito independiente se descontinuó cuando se lanzó el pago por uso en febrero de 2026, así que las cuentas nuevas deben comprar créditos antes de hacer cualquier llamada. El único acceso gratuito que sobrevive es un programa estrecho y con aprobación previa para apps de utilidad pública designadas.

Para quien todavía compara contra el nivel gratuito legado, sus límites de tasa siempre fueron severos por diseño:

• De solo escritura. Cero acceso de lectura de posts: ni cronologías, ni búsqueda, ni consulta de tweets.
• 17 solicitudes por cada 24 horas en el endpoint de publicación, sumando app y usuario, lo que en la práctica sale en unos 500 posts al mes, a pesar de la cifra de "1,500 posts al mes" que X promocionaba.
• Ventanas de 24 horas en lugar de las ventanas de 15 minutos, más amables, que usa el acceso de pago.

En otras palabras, el nivel gratuito nunca tuvo límites de tasa usables para leer datos de X, y hoy ya no existe para registros nuevos. La vía gratuita práctica para probar lecturas pasa por el acceso de terceros. Cada cuenta nueva de Sorsa incluye 100 solicitudes gratis por única vez: sin tarjeta, nunca vencen y funcionan con los 40 endpoints. Funcionan con el mismo límite de 20 solicitudes por segundo (20 req/s) que los planes de pago, y por los endpoints por lotes alcanzan para hasta 10,000 tweets o 20,000 perfiles antes de pagar nada. Para saber cómo funcionan hoy el acceso oficial y las claves, consulta nuestro recorrido de cómo obtener la clave API de X en 2026.

¿Cuántos tweets puedes extraer de verdad por día? {#how-many-tweets-can-you-actually-pull-per-day}

Los números de límite de tasa por sí solos no dicen mucho. Lo que importa es el throughput: cuántos tweets, perfiles o registros de seguidores puedes recolectar de forma realista en un día. Aquí están las cuentas para los escenarios más comunes, asumiendo autenticación por usuario.

Búsqueda de tweets (reciente)

• Límite de tasa: 300 solicitudes / 15 minutos = 1,200/hora = 28,800/día
• Resultados máximos por solicitud: 100
• Techo teórico: 2,880,000 tweets/día

Suena generoso, pero el tope de cobro del pago por uso es de 2 millones de lecturas de posts al mes. Quemarías la cuota mensual completa en menos de un día de búsqueda continua. El límite de tasa no es tu cuello de botella aquí. El tope mensual sí.

Cronologías de usuario

• Límite de tasa: 900 solicitudes / 15 minutos = 3,600/hora
• Resultados por solicitud: ~20 (varía)
• Techo teórico: ~72,000 tweets/hora por cuenta

Para recolectar cronologías individuales, los límites de tasa rara vez son la restricción. El límite real es cuántos tweets ha publicado la cuenta.

Seguidores

• Límite de tasa: 300 solicitudes / 15 minutos = 1,200/hora
• Resultados máximos por página: 1,000
• Techo teórico: 1,200,000 registros de seguidores/hora

X devuelve hasta 1,000 seguidores por página, lo que hace de este uno de sus endpoints de lectura con mayor throughput. Para comparar, en el modelo de tarifa plana de Sorsa el endpoint de seguidores devuelve hasta 200 perfiles por solicitud sin ventana de 15 minutos, solo con el mismo límite de 20 solicitudes por segundo (20 req/s) en todos los planes, lo que sale en unos 4,000 perfiles por segundo o cerca de 14.4 millones por hora. En grafos de seguidores muy grandes la diferencia se acumula rápido.

El cuello de botella real, resumido

Para trabajo intensivo en lecturas a cualquier escala significativa, lo primero con lo que chocas es el tope de cobro mensual, no el límite de tasa. Los límites de tasa se vuelven el cuello de botella práctico sobre todo en las operaciones de escritura, en las consultas de engagement con su techo ajustado de 75 por ventana y en los pipelines de alta concurrencia con autenticación de solo app.

Límites de tasa estándar vs Enterprise {#standard-vs-enterprise-rate-limits}

Todo lo de arriba describe los límites de tasa estándar (pago por uso). Enterprise es otro mundo. Los clientes Enterprise negocian límites personalizados directamente con el equipo de ventas de X, y los detalles no son públicos, pero la forma general se conoce:

• Límites por endpoint personalizados, típicamente mucho más altos que los estándar
• Topes de uso mensuales más altos o levantados (el techo de 2 millones de lecturas de posts puede desaparecer)
• Las operaciones de escritura de engagement que salieron del autoservicio en abril de 2026 (follows, likes y posts citados)
• Búsqueda de archivo completo con mayor concurrencia, más acceso a la Activity API y a webhooks con límites personalizados

El precio mínimo de Enterprise históricamente empieza alrededor de $42,000 al mes, aunque esto puede haber cambiado con la transición al pago por uso. La aprobación es selectiva y el onboarding puede tomar semanas.

¿Quién necesita Enterprise de verdad?

Enterprise encaja con grandes plataformas SaaS que revenden datos de X a sus propios clientes, con firmas financieras que corren modelos en tiempo real y con grupos de investigación que procesan millones de posts al mes. Si necesitas a la vez más de 2 millones de lecturas de posts al mes y acceso de escritura, Enterprise es tu única vía en la API oficial.

Para los equipos que necesitan alto throughput en operaciones de lectura sin pagar lo que cuesta Enterprise, este es justo el hueco que llenan los proveedores externos, y donde construimos Sorsa. Nuestro límite de 20 solicitudes por segundo se aplica en todos los planes, incluido el Starter de $49/mes, sin tablas por endpoint y sin ventanas de 15 minutos que administrar; el límite se puede subir a pedido para casos de uso de alto volumen a través de habla con ventas. La contrapartida honesta es que Sorsa es de solo lectura: no publica, no da likes, no sigue cuentas y no envía mensajes. Si todo lo que necesitas es la lectura individual más barata en términos absolutos y toleras armar la confiabilidad por tu cuenta, hay opciones más básicas; si quieres acceso de lectura completo y confiable a un precio fijo, ese es el caso para el que estamos construidos. Para una comparación de campo más amplia, consulta nuestro repaso de alternativas a la API de X.

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

En los endpoints por lotes de Sorsa eso sale desde $0.02 por cada 1,000 tweets, e incluso en la paginación de búsqueda simple se queda alrededor de $0.10 por cada 1,000 en el plan Pro, frente a $5.00 por cada 1,000 lecturas de posts en el pago por uso oficial. Para recolección intensiva en lecturas, eso sale hasta 50 veces más barato por lectura, y las ventanas por endpoint desaparecen por completo. La razón para quedarse en la API oficial son las operaciones de escritura: cualquier cosa que publique, envíe DMs o dé like todavía tiene que pasar por ahí, porque Sorsa es de solo lectura por diseño. El patrón práctico que vemos con más frecuencia es conservar las operaciones de escritura en la API oficial y mover la lectura pesada a una alternativa de tarifa plana; nuestra guía de migración cubre hacer ese cambio con limpieza.

Qué pasa cuando chocas con un límite de tasa (429) {#what-happens-when-you-hit-a-rate-limit-429}

Cuando excedes un límite de tasa, X devuelve HTTP 429 Too Many Requests (demasiadas solicitudes) con este cuerpo:

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

La respuesta todavía incluye los encabezados de límite de tasa, que es la parte que importa. x-rate-limit-reset te dice exactamente cuándo se reabre la ventana, así que nunca tienes que dormir a ciegas por un intervalo fijo.

Una estrategia de recuperación adecuada

El enfoque ingenuo duerme unos 15 minutos fijos y reintenta. Funciona, pero desperdicia tiempo. Un enfoque mejor lee la marca de tiempo de reinicio y espera solo lo que la ventana de verdad necesita:

import time
import requests

def request_with_rate_limit_handling(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)

        if response.status_code != 429:
            return response

        reset_timestamp = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset_timestamp - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until window resets.")
        time.sleep(wait_seconds + 1)  # +1s buffer

    raise Exception("Rate limit retries exhausted")

Unas cuantas cosas que vigilar:

No reintentes al instante. Un bucle de reintento sin retraso quema las solicitudes que te quedan en otros endpoints (con autenticación a nivel de app) y puede disparar un throttling más agresivo.

No ignores los 429 en pipelines masivos. En un bucle de recolección apretado, un 429 puede significar cientos de solicitudes fallidas antes de que tu código lo note. Revisa x-rate-limit-remaining antes de cada solicitud y pausa cuando caiga por debajo de 10 a 20.

Registra las solicitudes que te quedan. Cuando depuras problemas de límite de tasa, un registro de serie temporal de x-rate-limit-remaining es, con diferencia, el artefacto más útil. Muestra exactamente qué patrón de llamada está drenando tu presupuesto.

Comprueba con cuál de las tres capas chocaste de verdad. Un 429 con los encabezados de límite de tasa cerca de cero es la ventana del endpoint. Un bloqueo que persiste después de que la ventana se reinicia suele ser el tope de uso mensual o un tope a nivel de cuenta, y ninguna cantidad de backoff arregla eso.

Cómo mantenerte por debajo de los límites de tasa {#how-to-stay-under-rate-limits}

El consejo estándar ("cachea las respuestas" y "usa backoff exponencial") no está mal, pero es incompleto. Estos son los movimientos que de verdad cambian las cuentas, sacados de las migraciones de pipelines que hemos manejado.

1. Usa endpoints por lotes en lugar de consultas individuales

El endpoint /2/tweets acepta hasta 100 IDs de tweets en una sola solicitud: una solicitud, un golpe al límite de tasa, 100 tweets de vuelta. Hacer en su lugar 100 llamadas individuales a /2/tweets/:id gasta 100 golpes de un límite más ajustado (450/15min contra 3,500/15min por lotes). La misma lógica se aplica a /2/users, que acepta hasta 100 nombres de usuario o IDs.

Las APIs externas llevan el agrupamiento más lejos. Nuestro endpoint de tweets por lotes acepta 100 URLs o IDs de tweets por solicitud y nuestra consulta de perfiles por lotes acepta 100 perfiles, y cada una cuenta como una sola solicitud de tu cuota. Hay más tácticas para recortar el volumen de solicitudes en nuestras notas sobre cómo optimizar el uso de la API.

2. Usa streaming en lugar de sondeo

Sondear /2/tweets/search/recent cada 30 segundos significa 2,880 solicitudes al día a ese solo endpoint. El stream filtrado de X te envía en tiempo real los tweets que coinciden sobre una sola conexión persistente: una conexión, hasta 250 posts coincidentes por segundo. El detalle es que permite 50 intentos de conexión por cada 15 minutos y solo 1 conexión activa a la vez, pero para monitorear palabras clave o cuentas le gana al sondeo sin discusión. Vamos más a fondo en nuestra guía de monitoreo de Twitter en tiempo real.

3. Cachea los perfiles de usuario de forma agresiva

Los perfiles de usuario cambian despacio. Los nombres visibles, las bios y los conteos de seguidores se mueven en días, no en minutos. Si tu app trae datos de usuario junto con los tweets, cachea los perfiles con un TTL de 12 a 24 horas y sáltate la llamada cuando haya acierto de caché. Las métricas de engagement se mueven más rápido, así que un TTL de 1 a 6 horas suele ser lo correcto para analítica; los paneles en tiempo real no tienen buen sustituto para las llamadas frescas.

4. Monitorea los encabezados y regula de forma proactiva

No esperes un 429 para bajar el ritmo. Rastrea x-rate-limit-remaining en cada respuesta y agrega un umbral suave: cuando caiga por debajo de aproximadamente el 10 por ciento del límite, baja el ritmo antes de chocar con el muro.

remaining = int(response.headers.get("x-rate-limit-remaining", 100))
if remaining < 30:   # soft threshold
    time.sleep(2)    # gentle slowdown before the hard stop

5. Distribuye entre métodos de autenticación

Los límites por app y por usuario son pools independientes. Si te autenticas con un Bearer Token y con un token de usuario OAuth a la vez, obtienes en efecto dos cubos para los endpoints que admiten ambos. La consulta de tweets permite 3,500 por cada 15 minutos por app y 5,000 por cada 15 minutos por usuario, así que usar los dos suma 8,500 por cada 15 minutos. Esto solo ayuda si tu arquitectura admite rutas de autenticación dobles; es sencillo del lado del servidor y normalmente imposible en una app que solo vive en el cliente.

Una herramienta más que vale la pena conocer antes de quemar cuota real: X ofrece un API Playground autoalojado (lanzado en diciembre de 2025) que emula los endpoints de v2 en local, incluida la simulación de límites de tasa, así que puedes probar tu backoff y el manejo de encabezados sin gastar una sola solicitud en vivo.

En la práctica: un equipo de analítica fintech que seguía chocando con 429

Un equipo pequeño de analítica fintech (de unos ocho ingenieros) llegó a nosotros después de que su pipeline de datos de X se quedara atascado una y otra vez. Sondeaban la búsqueda reciente en un bucle de 30 segundos para atrapar los posts que mueven mercado, se abrían en abanico a consultas de perfil por autor y no entendían por qué un límite de "300 por cada 15 minutos" seguía produciendo 429 a mitad de recolección. La causa era la de siempre: la autenticación de solo app hacía que cada consulta de perfil y cada búsqueda salieran del mismo pool por app, y la cadencia de sondeo por sí sola se gastaba la mayor parte.

No los migramos fuera de la API oficial para las operaciones de escritura que todavía necesitaban; movimos la recolección intensiva en lecturas a un modelo de tarifa plana y cambiamos el sondeo por recolección basada en eventos. Con el precio por recurso de la API oficial, ese volumen de lectura quedaba en la zona incómoda entre el pago por uso barato y un contrato Enterprise de $42,000. Como nuestros planes de tarifa plana salen hasta 50 veces más baratos por lectura que la API oficial a ese volumen, el lado de lectura de su factura bajó a unos cuantos cientos de dólares al mes, y los 429 desaparecieron en cuanto las ventanas por endpoint quedaron fuera del panorama. El flujo de escritura se quedó en la API oficial, que es donde le toca.

Preguntas frecuentes {#frequently-asked-questions}

¿Los límites de tasa de la API de X son por usuario o por app?

Ambos, según el endpoint y tu método de autenticación. La autenticación con Bearer Token (solo app) usa límites por app, donde cada solicitud de tu aplicación comparte un mismo pool. La autenticación con token de usuario OAuth usa límites por usuario, donde cada usuario autenticado obtiene un cubo independiente. Muchos endpoints publican una cifra por app y otra por usuario; unos pocos publican solo una. Las tablas oficiales de límites de tasa de X especifican cuál se aplica a cada endpoint.

¿Cuál es el límite de tasa para publicar en la API de X?

El endpoint de escritura de la API (/2/tweets) permite 100 posts por cada 15 minutos por usuario y 10,000 por cada 24 horas por app, y el borrado se topa en 50 por cada 15 minutos por usuario. En la práctica, el tope a nivel de cuenta aprieta primero: una cuenta de X no verificada está limitada a 50 posts originales y 200 respuestas al día sumando API, web y celular.

¿Cuál es el límite de tasa para la búsqueda de la API de X?

La búsqueda reciente (/2/tweets/search/recent) permite 450 solicitudes por cada 15 minutos por app y 300 por cada 15 minutos por usuario, y devuelve hasta 100 resultados en cada una con un límite de consulta de 512 caracteres. La búsqueda de archivo completo (/2/tweets/search/all) permite 1 solicitud por segundo con un techo de 300 por cada 15 minutos, devuelve hasta 500 resultados por llamada, se remonta a 2006 y solo está disponible en planes de pago.

¿Cuánto duran las ventanas de límite de tasa de la API de X?

La mayoría de los endpoints de la API de X v2 usan ventanas deslizantes de 15 minutos. Algunos usan ventanas de 24 horas, entre ellos el endpoint de publicación (10,000 por cada 24 horas por app), las subidas de multimedia y varios topes de mensajes directos, y unos cuantos endpoints de streaming y de archivo agregan un tope por segundo. Cada ventana empieza en tu primera solicitud a ese endpoint, no en una hora de reloj fija.

¿La API de X tiene un nivel gratuito con límites de tasa usables en 2026?

No. X descontinuó el nivel gratuito independiente en febrero de 2026, y los nuevos desarrolladores empiezan en pago por uso sin cuota gratuita. El nivel gratuito legado era de solo escritura, topado en 17 solicitudes por cada 24 horas en el endpoint de publicación y con cero acceso de lectura de posts, así que nunca sirvió para leer datos de X a escala. El único acceso gratuito hoy es un programa con aprobación previa para apps de utilidad pública designadas. Para probar el acceso de lectura sin pagar, Sorsa API incluye 100 solicitudes gratis al registrarte: por única vez, sin tarjeta, nunca vencen y funcionan con los 40 endpoints.

¿Los límites de cuenta de X son lo mismo que sus límites de tasa de la API?

No, son sistemas separados. Los límites de tasa de la API rigen qué tan rápido puede una app de desarrollador llamar a cada endpoint (por ejemplo, 100 posts por cada 15 minutos por usuario). Los límites de cuenta rigen qué puede hacer una cuenta de X en toda la plataforma (por ejemplo, 50 posts originales al día para una cuenta no verificada). Y algo crucial: los límites de cuenta cuentan también las acciones por API, así que los posts automatizados y los manuales comparten un mismo presupuesto diario.

¿Puedo subir los límites de tasa de la API de X sin Enterprise?

En la API oficial, no. Los límites de tasa estándar son fijos y solo suben bajo un acuerdo Enterprise. Los rodeos disponibles son el agrupamiento en lotes (más datos por solicitud), el streaming (evitar el sondeo) y distribuir las solicitudes entre la autenticación de app y la de usuario. Fuera de la API oficial, los proveedores externos enfocados en lectura suelen aplicar un único límite fijo por segundo en lugar de ventanas por endpoint, y lo suben a pedido.

¿Cómo consiguen quienes desarrollan un alto throughput de lectura sin un contrato Enterprise?

La mayoría mueve el trabajo intensivo en lecturas a una alternativa a la API de Twitter/X con un límite de tasa fijo en lugar de ventanas por endpoint. Sorsa API, por ejemplo, atiende sus 40 endpoints de lectura con el mismo límite de 20 solicitudes por segundo (20 req/s) en todos los planes, desde $0.02 por cada 1,000 tweets en los endpoints por lotes y con planes desde $49 al mes. A escala de lectura eso sale hasta 50 veces más barato por lectura de post que el precio por recurso de la API oficial, y elimina las ventanas de 15 minutos y la división por app contra por usuario que causan la mayoría de los 429 en los pipelines de recolección.

Cómo empezar

Si las ventanas por endpoint y los 429 de arriba son el problema del que intentas salir, la forma más rápida de sentir la diferencia es correr unas cuantas llamadas por tu cuenta. 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 inicio rápido de Sorsa API te deja autenticado con una sola clave API en unos minutos, y cada cuenta nueva incluye 100 solicitudes gratis por única vez: sin tarjeta, nunca vencen y funcionan con los 40 endpoints, suficientes para hasta 10,000 tweets o 20,000 perfiles por los endpoints por lotes. Más allá de eso, los planes de precios parten de $0.02 por cada 1,000 tweets en los endpoints por lotes, con planes desde $49 al mes y el mismo límite de 20 solicitudes por segundo cubierto arriba. Sin revisión de app, sin pasar por el flujo de OAuth y sin tablas de límites 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: cada cifra de endpoint de aquí se leyó directo de las tablas oficiales de límites de tasa de X, y los topes a nivel de cuenta salen de la documentación de límites de X, ambos revisados de nuevo el 31 de julio de 2026, porque estos números cambian sin mucho aviso (X recortó el tope diario de posts de las cuentas no verificadas de 2,400 a 50 apenas en mayo de 2026, y pasó las operaciones de escritura de engagement a solo Enterprise en abril de 2026). Las cuentas de throughput, el código de recuperación del 429 y el encuadre de "qué límite llega primero" salen de nuestro propio trabajo construyendo y operando una API alternativa de Twitter/X y de las migraciones de pipelines de lectura que maneja nuestro equipo, incluido el caso fintech anonimizado de arriba (detalles fusionados y despojados de cualquier cosa identificable). Las afirmaciones sobre precios y topes de uso se resumen de nuestra cobertura aparte de precios de la API de X; para saber quiénes somos y cómo contactarnos, consulta Acerca de Sorsa. Ninguna estadística, fuente ni resultado de cliente de aquí está inventado.