X dejó de publicar los rate limits de la API de Twitter por plan

¿Cuáles son los rate limits de la API de Twitter en 2026?

Nada en la documentación actual de X fija los rate limits de la API de Twitter por plan. Las tablas en vivo están organizadas por endpoint y divididas en dos columnas, una para los límites por app que se aplican cuando te autenticas con un bearer token y otra para los límites por usuario que se aplican bajo tokens de usuario de OAuth 1.0a u OAuth 2.0. Cada cifra de abajo sale de docs.x.com/x-api/fundamentals/rate-limits, leída el 12 de septiembre de 2026.

Las ventanas son de 15 minutos salvo que la entrada diga otra cosa. Estos son los endpoints que un sistema de escucha o monitorización toca de verdad.

Dos entradas de esa tabla merecen una mirada larga. Recent search da a una app 450 solicitudes y a un usuario solo 300, así que el bearer token de app es la credencial más fuerte para monitorizar. Full-archive search se gobierna tanto por un límite por segundo como por uno por ventana, lo que significa que un trabajo de relleno necesita un sleep entre llamadas en vez de una ráfaga y una espera.

¿A qué planes se aplican los rate limits de la API de Twitter?

X opera ahora dos niveles comerciales, pago por uso y Enterprise, y los planes de suscripción Free, Basic y Pro que las guías viejas todavía citan ya no existen. El changelog fecha el cambio. X anunció el piloto de pago por uso el 20 de octubre de 2025 y lanzó los precios de pago por uso el 6 de febrero de 2026 con Basic y Pro todavía disponibles, y después migró a los suscriptores de Basic a partir del 1 de junio de 2026 y a los de Pro a partir del 1 de septiembre de 2026. Las tablas de rate limits de arriba no llevan ninguna columna de plan, y esa es la respuesta honesta a "cuáles son los límites en Basic". No hay Basic.

Donde X sí sigue dividiendo por nivel, las cifras se ven así.

¿En qué se contradice X con estas cifras?

Tres páginas activas en docs.x.com se contradicen entre sí, y las discrepancias no son cosméticas.

La primera es el número de reglas de filtered stream. La página de introducción al filtered stream sitúa a Enterprise en "25,000+" reglas por proyecto. La página de precios de Enterprise, que describe el mismo producto, lo sitúa en "5,000+ rules". Las dos páginas estaban activas el 12 de septiembre de 2026 y ninguna enlaza a la otra como corrección.

La segunda es la longitud de consulta en los conteos de posts. La tabla de rate limits lista /2/tweets/counts/all con una nota de "1024 query length". La página del constructor de consultas de conteos dice "Your query can be 512 characters long for pay-per-use customers, or up to 4,096 characters for Enterprise customers", cubriendo los dos endpoints de conteo con una sola cifra. Una consulta escrita con 1.024 caracteres contra /2/tweets/counts/all queda entonces dentro del límite de una página y fuera del de la otra.

La tercera es una referencia colgada. Los dos constructores de consultas de búsqueda y el constructor de reglas del filtered stream te dicen que tus límites dependen de tu nivel de acceso y enlazan a /x-api/getting-started/about-x-api para el detalle. Esa página ya no contiene una sección de nivel de acceso. Tiene capacidades, versiones de la API, recursos y precios de pago por uso, y nada que nombre un plan. La página en docs.x.com/fundamentals/rate-limits lleva la descripción "Understand X API rate limits across access tiers and endpoints" y luego no lista ningún plan, solo un enlace hacia la tabla de endpoints.

La lección para quien presupueste un desarrollo es tratar la tabla por endpoint como el documento operativo y las páginas de texto como material caducado.

¿Cómo se leen las cabeceras de rate limit?

X devuelve tres cabeceras en cada respuesta, y son la única fuente de verdad en tiempo real.

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 y x-rate-limit-reset es una marca de tiempo Unix para el momento en que la ventana se renueva. Cruza el techo y recibes un 429 con este cuerpo:

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

El error code: 88 ha sobrevivido a todas las reescrituras de esta API desde la v1.1, así que vale la pena comprobarlo de forma explícita y no solo el código de estado. El consejo de recuperación de la propia X es leer x-rate-limit-reset, esperar hasta esa marca de tiempo y aplicar retroceso exponencial a partir de ahí.

¿Son los rate limits lo mismo que tu factura?

No, y X enuncia la separación directamente: los rate limits controlan la frecuencia de solicitudes para dar estabilidad al sistema, mientras que la facturación por uso cobra los datos recuperados. Puedes quedarte dentro de todos los rate limits y aun así gastar, y puedes chocar con un rate limit sin gastar nada extra.

Las lecturas se cobran por recurso devuelto, no por solicitud. Un post leído cuesta $0.005 y un usuario leído cuesta $0.010. Los recursos se deduplican dentro de una ventana de 24 horas UTC, así que pedir el mismo post dos veces en un día se cobra una vez, y X llama a esa deduplicación una garantía blanda y no una promesa. El plan de pago por uso tiene un tope de 3 millones de posts leídos por ciclo de facturación mensual por muy suave que sea tu ritmo de solicitudes. El cuadro completo de costes, incluido el lado de escritura, está desglosado en la nota sobre los precios de la API de X.

¿Qué límite frena de verdad un sistema de monitorización?

El tope mensual de posts leídos, no el límite de solicitudes por ventana. Recent search a 450 solicitudes por 15 minutos con 100 resultados por solicitud son 45.000 posts por ventana sobre el papel, lo que agotaría un cupo de 3 millones de posts en menos de un día de sondeo continuo. El techo de solicitudes es generoso; el techo de recursos es el presupuesto.

Eso cambia la forma de una buena consulta. Las reglas estrechas que devuelven pocas coincidencias cuestan poco, y una regla amplia que casa con una palabra común quema el cupo mientras duermes. El filtered stream es el instrumento más barato para cobertura continua porque entrega solo lo que encaja con tus reglas, y mantener las reglas no cuesta nada. Escribir bien esas reglas es la misma habilidad que escribir una buena consulta de búsqueda, algo que cubre la referencia sobre los operadores de búsqueda avanzada de X.

La otra mitad del cálculo es que X es una sola red. Una pregunta de compra hecha en X suele hacerse también en Reddit y en Hacker News, y esas plataformas miden el acceso de otra manera, como muestra la comparación de rate limits de la API de Reddit. Los equipos que empezaron con la API de X y luego pusieron precio al hueco de cobertura acaban más bien escuchando en varias redes en vez de pagando por ensanchar una.

Preguntas frecuentes

¿Cuál es el rate limit de la API de búsqueda de X?

Recent search en /2/tweets/search/recent permite 450 solicitudes por 15 minutos con un bearer token de app y 300 por 15 minutos con un token de usuario, devolviendo 10 resultados por defecto y 100 como máximo. Full-archive search en /2/tweets/search/all permite 1 solicitud por segundo y 300 por 15 minutos por app, devolviendo 10 por defecto y 500 como máximo.

¿X sigue teniendo un plan Free?

No como producto documentado. X lanzó los precios de pago por uso el 6 de febrero de 2026 y su documentación actual de acceso te guía para registrarte, crear una app y guardar credenciales sin nombrar ningún plan. La palabra "Free" sobrevive solo en entradas del changelog, entre ellas la nota del 22 de agosto de 2025 que retiró POST /2/users/:id/likes y POST /2/users/:id/following del plan Free.

¿Qué significa un HTTP 429 en la API de X?

Significa que superaste un rate limit de ese endpoint en la ventana actual. El cuerpo de la respuesta lleva code: 88 y el mensaje "Rate limit exceeded". Lee la cabecera x-rate-limit-reset para saber la marca de tiempo Unix en que se reinicia la ventana, y no reintentes antes.

¿Los rate limits se cuentan por app o por usuario?

Los dos, y cuál se aplica depende de cómo te hayas autenticado. Las solicitudes con bearer token cuentan contra el límite por app, y las solicitudes con token de usuario de OAuth 1.0a u OAuth 2.0 cuentan contra el límite por usuario de esa persona. Varios endpoints publican solo una de las dos columnas, lo que significa que el otro modo de autenticación ni siquiera se ofrece ahí.

¿Cuántas reglas de filtered stream puedo tener activas?

Un proyecto de pago por uso recibe 1.000 reglas de hasta 1.024 caracteres cada una, sobre una única conexión, con la entrega limitada a 250 posts por segundo. Enterprise sube la longitud de regla a 2.048 caracteres y permite varias conexiones. El número de reglas de Enterprise es justo donde las propias páginas de X se contradicen, con 25.000+ en la introducción al filtered stream y 5.000+ en la página de precios de Enterprise.

¿Los rate limits se aplican también al endpoint de uso?

Sí. GET /2/usage/tweets, el endpoint que informa de tu propio consumo de posts, tiene un tope de 50 solicitudes por 15 minutos por app y no ofrece límite por usuario. Consultar tu propio gasto es barato, pero no queda fuera de la contabilidad, así que léelo con una programación en vez de antes de cada llamada.

¿Cuánto cobra la API de X por cada Post read?

Un Post read cuesta 0,005 $ y un user read cuesta 0,010 $, cobrados por recurso devuelto y no por solicitud. X deduplica los recursos dentro de una ventana de 24 horas en UTC, así que pedir el mismo Post dos veces en un día cuenta una sola vez, aunque X llama a esa deduplicación una garantía blanda y no una promesa. El plan pay-per-use limita los Post reads a 3 millones por ciclo de facturación sin importar el ritmo de las solicitudes.

¿Cuándo retiró X los niveles Basic y Pro?

X lanzó el precio pay-per-use el 6 de febrero de 2026 con Basic y Pro todavía disponibles, y después dejó ambos obsoletos. Los suscriptores de Basic migraron a partir del 1 de junio de 2026 y los de Pro a partir del 1 de septiembre de 2026, y quedaron Enterprise y pay-per-use. Las guías antiguas que todavía citan límites de Basic o Pro describen una estructura de precios que ya no existe.

¿Por qué el rate limit por usuario es más alto que el rate limit por app en algunos endpoints?

No hay una regla única. En /2/tweets, un token de app recibe 3.500 solicitudes cada 15 minutos mientras que un token de usuario recibe 5.000, y /2/tweets/:id sigue el mismo patrón con 450 frente a 900. La búsqueda reciente funciona al revés, con 450 por app frente a 300 por usuario, así que la credencial más fuerte depende del endpoint que llames y no de una jerarquía fija entre autenticación de app y de usuario.

¿Cuál es la forma más barata de mantener monitorización continua en X?

El filtered stream, no el sondeo con search. La búsqueda reciente, con 450 solicitudes cada 15 minutos y 100 resultados por llamada, puede devolver hasta 45.000 Posts por ventana sobre el papel, suficiente para agotar una asignación mensual de 3 millones de Posts en menos de un día de sondeo continuo. El filtered stream entrega solo lo que coincide con tus reglas, y mantener esas reglas no cuesta nada, así que un conjunto de reglas bien acotado cubre el mismo terreno por una fracción de los reads.