Límites de publicación de la API de X (Twitter) 2026: tweets por día

Por Sorsa Editorial

Actualizado el 11 de julio de 2026: declara los topes confirmados de cuentas no verificadas (50 posts originales y 200 respuestas por día, según la página de límites de X desde mediados de mayo de 2026), quita la cifra diaria de Premium sin publicar, y replantea el límite de ritmo como los sub-límites cada media hora documentados por X.

Conclusión clave: El endpoint de escritura de la API de X permite 100 posts por cada 15 minutos por usuario y 10,000 por cada 24 horas por app. Aparte, la cuenta de X carga topes a nivel de plataforma que cuentan juntos los posts de API y manuales: desde mayo de 2026, las cuentas no verificadas tienen 50 posts originales y 200 respuestas por día, y este tope de cuenta detiene primero a la mayoría de las automatizaciones.

Publicar por la API de X en 2026 choca con tres techos separados, no uno, y se aplican de forma independiente. El endpoint de la API tiene sus propios límites de tasa por app y por usuario. La cuenta de X desde la que publicas tiene topes diarios a nivel de plataforma que aplican sea que el post haya venido de un script o de la app de celular. Y en pago por uso, cada post creado se cobra, con un tope duro de 2 millones de lecturas de posts en el lado de lectura de la misma cuenta. Cualquiera de los tres puede devolver un error, y por eso "mi código no está ni cerca del límite de tasa" es una de las quejas más comunes y confusas de quienes automatizan X.

Esta guía cubre las tres capas con números vigentes, verificados contra la propia documentación de X. Nosotros construimos y operamos Sorsa API, una API alternativa de Twitter/X para leer datos públicos de X, así que publicar en sí no es nuestro terreno: las escrituras pertenecen a la API oficial, y estos son los límites con los que vives ahí. Donde sí podemos ayudar es en la otra mitad de la mayoría de los flujos de publicación, la parte de lectura, confirmar que un post salió en vivo, extraer su engagement o monitorear menciones tras publicar, que las secciones de abajo señalan donde corresponde. Los números de publicación aquí son lo que la API oficial de X te da ahora mismo.

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

Contenido

Cómo funcionan los límites de publicación de la API de X
¿Cuántos tweets puedes publicar por día por la API de X?
Límites de tasa para respuestas, borrados y mensajes directos
¿Qué pasa con los likes, follows y reposts?
¿El nivel gratuito de la API de X te deja publicar en 2026?
El ritmo cada media hora que detiene a la mayoría de las automatizaciones
Qué pasa cuando llegas a un límite de publicación
Cómo publicar a escala sin disparar los límites
Preguntas frecuentes

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

X aplica la publicación en tres capas independientes en 2026: el límite de tasa de la API en el endpoint de escritura, el tope diario a nivel de cuenta en la cuenta de X misma, y el cobro de pago por uso que mide cada post creado. Una solicitud puede fallar contra cualquiera de ellos, y cada uno devuelve una señal distinta.

La primera capa es el límite de tasa de la API. El endpoint de escritura (POST /2/tweets) permite 100 posts por cada 15 minutos por usuario y 10,000 por cada 24 horas por app. Son ventanas móviles que arrancan desde tu primera solicitud, no desde una hora de reloj fija, y romper una devuelve HTTP 429.

La segunda capa es el tope de cuenta. Cada cuenta de X está atada por límites de publicación a nivel de plataforma que rigen en web, celular y API juntos. La propia documentación de límites de X es explícita en que estos topes diarios cuentan acciones "desde todos los dispositivos, incluidos web, celular, teléfono, API", así que un post automatizado y un post escrito a mano salen del mismo presupuesto diario. Esta es la capa que la mayoría de las guías pasa por alto, y suele ser la que de verdad detiene a un bot.

La tercera capa es el cobro. Desde que X pasó al pago por uso en febrero de 2026, cada post creado cuesta dinero ($0.015 por un post simple, $0.20 por un post que contiene una URL a partir de la nueva tarificación del 20 de abril de 2026), y la cuenta carga un tope duro separado de 2 millones de lecturas de posts al mes en el lado de lectura. Puedes estar cómodamente dentro de tu límite de tasa de publicación y aun así quedar bloqueado en lecturas, o ver un flujo de publicación pesado en enlaces volverse caro rápido. El panorama completo de costo por acción, incluidos el premium por URL y la ventana de deduplicación, está en el desglose de precios de la API de X de 2026.

La conclusión práctica: el límite de tasa de la API rara vez es la restricción vinculante para publicar. El tope de cuenta casi siempre lo es.

¿Cuántos tweets puedes publicar por día por la API de X? {#how-many-tweets-can-you-post-per-day-via-the-x-api}

Por la API sola, un solo usuario autenticado puede publicar hasta 100 tweets por cada 15 minutos, y una app puede publicar hasta 10,000 por cada 24 horas entre todos sus usuarios. Pero la cuenta de X de la que salen esos posts está topada por separado a nivel de plataforma, y ese tope de cuenta es más bajo que el techo de la API y normalmente lo que detiene la automatización.

Así se apilan las dos capas para una sola cuenta:

Capa	Límite	Ventana	Aplica a
API por usuario (`POST /2/tweets`)	100 posts	15 min	Cada token de usuario autenticado
API por app (`POST /2/tweets`)	10,000 posts	24 hrs	Toda la app, todos los usuarios combinados
Tope de cuenta, no verificada	50 posts + 200 respuestas	24 hrs	La cuenta de X, API y manual combinados
Sub-límites de ritmo de cuenta	Sin publicar	Cada media hora	La cuenta de X, cualquier fuente

Desde mediados de mayo de 2026, la propia página de límites de X topa las cuentas no verificadas en 50 posts originales y 200 respuestas por día, un recorte fuerte respecto a los longevos 2,400, y parte ese presupuesto diario en sub-límites cada media hora cuyas cifras de intervalo X no publica. Se reporta ampliamente que los reposts y los posts citados cuentan hacia los 50, aunque X no lo ha confirmado de plano, y la página de ayuda todavía referencia el viejo número de 2,400 en partes, y por eso circulan cifras contradictorias entre las guías. Las cuentas verificadas (Premium) están exentas de estos topes publicados; X no declara una cifra para ellas, así que en una cuenta Premium los límites de escritura de la API de arriba se vuelven el techo práctico.

La trampa es diseñar alrededor del límite de la API. Quien desarrolla lee "100 posts por cada 15 minutos" (casi 9,600 al día por usuario) y construye para eso, y luego el bot se atasca mucho antes porque el tope a nivel de cuenta y su ritmo cada media hora atan primero. Para una cuenta no verificada corriendo automatización, 50 posts al día es el techo real, no la ventana de la API.

Este comportamiento por capas también aparece en el lado de lectura, donde las ventanas de 15 minutos y los pools por app contra por usuario causan la mayoría de los 429 de los pipelines de recolección. Esos límites de lectura se cubren endpoint por endpoint en la referencia complementaria de límites de tasa de la API de X.

Límites de tasa para respuestas, borrados y mensajes directos {#rate-limits-for-replies-deletes-and-direct-messages}

Publicar un tweet de nivel superior, publicar una respuesta, borrar un tweet y enviar un mensaje directo operan cada uno bajo límites de escritura separados en la API de X. Una respuesta usa el mismo endpoint y límite POST /2/tweets que un post original, pero el borrado y el envío de DM son más estrictos y se rigen por sus propias ventanas.

Acción	Endpoint	Por usuario	Por app	Ventana
Publicar tweet o respuesta	`POST /2/tweets`	100	10,000	15 min (usuario), 24 hrs (app)
Borrar tweet	`DELETE /2/tweets/:id`	50	no disponible	15 min
Enviar mensaje directo	`POST /2/dm_conversations/.../messages`	15 por 15 min + 1,440 por 24 hrs	1,440	15 min y 24 hrs
Leer mensajes directos	`GET /2/dm_events`	15	no disponible	15 min

El borrado es el que sorprende a quienes corren trabajos de limpieza. A 50 borrados por cada 15 minutos por usuario, limpiar 1,000 tweets viejos toma aproximadamente cinco horas de tiempo real, ritmadas a lo largo de veinte ventanas, y no hay un endpoint de borrado por lotes para acelerarlo. Las herramientas que borran cronologías grandes lo logran diseñando los estados de espera, no reintentando más rápido.

Las respuestas cargan su propio tope a nivel de cuenta encima del límite de la API. Para las cuentas no verificadas, la página de límites de X fija ese tope de respuestas en 200 por día, separado del presupuesto de 50 posts originales, así que un bot que responde menciones puede agotar su asignación de respuestas mientras el presupuesto de posts originales queda intacto.

Los mensajes directos son deliberadamente lentos. A 15 envíos por cada 15 minutos por usuario más un techo de 1,440 por cada 24 horas, y un tope a nivel de plataforma ampliamente citado en unos 500 DMs por día por cuenta, el mensajeo automatizado choca con un muro rápido por diseño. Ninguna de estas acciones de escritura tiene un equivalente de solo lectura: leer el historial de DMs, por ejemplo, también está limitado a 15 solicitudes por cada 15 minutos, así que los flujos pesados en DMs están restringidos por ambos lados.

¿Qué pasa con los likes, follows y reposts? {#what-about-likes-follows-and-reposts}

Seguir cuentas, dar like a posts y citar posts cambiaron de nivel de acceso en 2026. A partir del 20 de abril de 2026, X sacó estas acciones de escritura de engagement del pago por uso de autoservicio y las hizo solo Enterprise, así que una automatización que da like, sigue o cita posts por código ahora necesita un contrato Enterprise en lugar de una app de desarrollador estándar. Publicar y los mensajes directos se quedaron en pago por uso.

Antes de ese cambio, los límites de API publicados para estas acciones eran ajustados: los likes y follows corrían a unos 50 por cada 15 minutos por usuario, con techos adicionales de 24 horas, y los reposts a una cadencia similar. Esos números ahora son irrelevantes para los usuarios de autoservicio, porque los endpoints están detrás del acceso Enterprise por completo.

A nivel de cuenta, los follows siguen topados por separado de los posts. Las cuentas no verificadas se reportan ampliamente en unos 400 follows por día y las cuentas Premium en unos 1,000, con X vigilando patrones de ciclos de seguir y dejar de seguir que disparan restricciones incluso cuando el número diario no se rompe. Los likes no tienen un límite de cuenta documentado públicamente, pero el like automatizado agresivo dispara de forma confiable el throttling por comportamiento.

Si tu flujo depende de escrituras de engagement por código, el nivel Enterprise de la API oficial es la vía conforme, y no hay sustituto de solo lectura para una acción de escritura. Lo que una API de lectura sí cubre es el lado de medición: en lugar de dar like o seguir, lees quién interactuó. Extraer las cuentas que hicieron repost o respondieron a un tweet de campaña es una operación de lectura, manejada por endpoints como la consulta de retweeters y de quienes respondieron, que mantiene esa recolección de datos fuera de cualquier cuenta de usuario por completo.

¿El nivel gratuito de la API de X te deja publicar en 2026? {#does-the-x-api-free-tier-let-you-post-in-2026}

No hay un nivel gratuito general de la API de X para nuevos desarrolladores en 2026. X descontinuó el nivel gratuito independiente cuando lanzó el pago por uso en febrero de 2026, así que una cuenta nueva debe comprar créditos antes de publicar un solo tweet. Si la API de X es gratis siquiera en 2026 tiene una respuesta para los registros nuevos: no lo es.

Para quien todavía tiene una app del nivel gratuito legado, la asignación de publicación siempre fue mínima por diseño. El nivel gratuito legado era de solo escritura y medido en ventanas de 24 horas, y la asignación documentada de POST /2/tweets era de 17 solicitudes por cada 24 horas compartidas entre toda la app (algunas fuentes citan una cifra mensual más alta que aplicaba a la vieja vía v1.1, que es la raíz de la confusión de 17-contra-50 que verás entre las guías). En cualquier caso, era una versión mínima pensada para probar una integración de publicación, nunca para correr una a volumen, y otorgaba cero acceso de lectura de posts.

Así que el nivel gratuito nunca permitió publicar a escala, y para los nuevos desarrolladores ya no existe. Si lo que de verdad necesitas probar es leer datos de X en lugar de publicarlos, el acceso de terceros es la vía gratuita práctica. Cada cuenta nueva de Sorsa incluye 100 solicitudes gratis, por única vez, sin tarjeta, y nunca vencen. Cubren los 40 endpoints de lectura a la misma tarifa plana que los planes de pago, que por los endpoints por lotes alcanza para hasta 10,000 tweets o 20,000 perfiles antes de pagar nada. Esa es una carga real para validar una integración de lectura, muy por encima de los pequeños créditos de prueba que dan la mayoría de los proveedores.

El ritmo cada media hora que detiene a la mayoría de las automatizaciones {#the-semi-hourly-pacing-that-stops-most-automations}

El límite que atrapa a más automatizaciones de publicación no es el número diario de portada por sí solo. X parte el presupuesto diario de publicación de cada cuenta en sub-límites más chicos cada media hora, aplicados a nivel de cuenta encima del tope diario e independientes del límite de tasa de la API, y no publica las cifras de intervalo. Quienes publican en vivo, corren hilos y los bots de respuesta disparan este ritmo constantemente, a veces antes de que el techo diario aparezca a la vista.

La razón de que sea tan fácil dispararlo es que el presupuesto es chico y compartido: 50 posts originales y 200 respuestas por día para una cuenta no verificada, con reposts y posts citados ampliamente reportados como que salen del mismo pool, todo ritmado en sub-intervalos. Un bot que responde una ráfaga de menciones, o un hilo publicado tweet por tweet en un bucle apretado, puede agotar la asignación de un intervalo en menos de un minuto y luego atascarse hasta que se reinicia.

Hay un segundo bloqueador, más silencioso, encima: la detección de duplicados. X rechaza posts con texto idéntico o casi idéntico publicados dentro de un lapso de unas 24 a 48 horas, devolviendo el código de error 187. Las automatizaciones que reciclan el mismo mensaje, común en la publicación evergreen o en configuraciones de varias cuentas, disparan esto incluso cuando no están ni cerca de ningún límite de tasa. El arreglo es trivial, cambiar hasta un carácter o un signo de puntuación libera la comprobación de duplicados, pero tiene que estar construido en el flujo.

La regla práctica para ritmar las escrituras: reparte los posts a lo largo del día en lugar de estallar contra el tope diario. Pon en cola las respuestas y los segmentos de hilo en lotes de 10 a 15 con huecos deliberados entre ellos, y varía cualquier texto reciclado. Diseñar solo al número diario es exactamente cómo las automatizaciones se atascan a mitad de la corrida.

Qué pasa cuando llegas a un límite de publicación {#what-happens-when-you-hit-a-posting-limit}

Cuando excedes un límite de tasa de la API, X devuelve HTTP 429 con el código de error 88:

json

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

La respuesta todavía carga los encabezados de límite de tasa, que es la parte que importa. x-rate-limit-reset es una marca de tiempo Unix de cuándo se reabre la ventana, así que un worker de escritura nunca tiene que dormir a ciegas por un intervalo fijo. Las roturas del tope a nivel de cuenta y los rechazos por duplicado se muestran distinto: un tope de cuenta tiende a devolver un 403 o un aviso de restricción de publicación en lugar de un 429, y un duplicado devuelve el error 187, así que un publicador bien construido distingue los tres en lugar de tratar cada falla como un límite de tasa.

Un reintento consciente del reinicio para la vía de escritura se ve así:

python

import time
import requests

def post_tweet_with_retry(text, headers, max_retries=3):
    url = "https://api.x.com/2/tweets"
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json={"text": text})

        if response.status_code != 429:
            return response

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

    raise Exception("Rate limit retries exhausted")

Dos cosas a vigilar. Primero, no reintentes al instante ante un 429, porque un bucle de reintento apretado quema el presupuesto restante entre otros endpoints en la autenticación de solo app. Segundo, revisa x-rate-limit-remaining antes de cada escritura y baja el ritmo cuando caiga a dígitos de un solo número, en lugar de esperar el freno duro. En un bucle de publicación o borrado masivo, un 429 sin manejar puede cascadear en una serie de fallas antes de que el código lo note.

Cómo publicar a escala sin disparar los límites {#how-to-post-at-scale-without-tripping-limits}

Sacar volumen real de publicación por la API de X va menos del techo diario y más del ritmo bajo la ventana de 30 minutos y el tope de cuenta. Estos son los movimientos que de verdad cambian el resultado.

Ritma a los sub-límites cada media hora, no solo al tope diario. X divide el presupuesto diario en intervalos cada media hora con cifras sin publicar, así que agrupa las respuestas y los segmentos de hilo en grupos de 10 a 15 con huecos en lugar de estallar. Este ritmo es lo que ata primero para casi toda automatización.
Usa una cuenta verificada (Premium) para publicación de alto volumen. Los topes diarios de 50 posts y 200 respuestas aplican solo a las cuentas no verificadas; la página de límites de X exime a las cuentas verificadas y no publica una cifra para ellas, así que el límite de escritura de la API se vuelve el freno real.
Varía cualquier texto reciclado para librar la detección de duplicados. El error 187 rechaza posts casi idénticos dentro de un lapso de 24 a 48 horas. Rota la redacción, o agrega un elemento único, en la publicación evergreen o de varias cuentas.
Vigila el premium por URL en tu modelo de costo. Un post que contiene cualquier enlace se cobra a $0.20 contra $0.015 por un post simple, más de 13 veces el costo, así que un flujo de publicación pesado en enlaces puede irse a dinero de verdad rápido. El cálculo detrás de ese salto está en nuestra mirada a por qué la API de X se vuelve tan cara.
Separa las colas de escritura de las colas de lectura. Publicar y leer salen de límites distintos y, en pago por uso, de topes distintos (el tope mensual de 2 millones de lecturas de posts es separado de cualquier presupuesto de escritura). Mantener las colas independientes significa que un atraso de lectura no puede bloquear un post programado, y viceversa.

Ese último punto es donde la mayoría de las configuraciones de publicación de producción terminan divididas entre dos proveedores, y lleva directo al patrón práctico de abajo.

Publicar contra leer: qué API para qué trabajo {#posting-versus-reading}

La mayoría de los flujos reales de X hacen ambas cosas, y las dos mitades pertenecen a infraestructura distinta en 2026. Escribir en X (publicar, responder, enviar DMs) es una acción de primera parte que tiene que correr en la API oficial, bajo los límites de arriba y sobre tokens autenticados de usuario. Leer X a volumen (verificar que un post se publicó, extraer su engagement, monitorear menciones, recolectar cronologías) es donde el precio por recurso oficial y las ventanas por endpoint se vuelven caras e incómodas, y donde una API de lectura de tarifa plana es un encaje más limpio.

Publicación automatizada, respuestas, DMs: la API oficial de X, en pago por uso o Enterprise. No hay sustituto conforme de solo lectura para una escritura.
Likes, follows, posts citados por código: el nivel Enterprise de la API oficial de X, porque estos dejaron el autoservicio el 20 de abril de 2026.
Confirmar que los posts salieron en vivo, extraer engagement, monitorear menciones, lecturas masivas: una alternativa enfocada en lectura como Sorsa, a 20 solicitudes por segundo sin ventanas por endpoint y lecturas desde $0.02 por cada 1,000 tweets en la base por lotes.

La división honesta vale decirla sin rodeos: si necesitas escribir en X, ese es territorio de la API oficial, y nada aquí cambia eso. Para la mitad intensiva en lecturas del mismo flujo, una API de lectura de tarifa plana y predecible elimina las ventanas de 15 minutos y el cobro por recurso. Mover solo las lecturas es un primer paso común, y la vía de migración desde la API oficial cubre hacerlo sin tocar el lado de escritura.

En la práctica: una agencia a la que restringían la publicación una y otra vez

Una agencia social (de una docena de personas) que corría posts programados para clientes seguía chocando con restricciones de publicación que no podía explicar. Su programador estaba arquitecturado alrededor de la cifra de la API de "100 por cada 15 minutos", pero las cuentas de clientes seguían quedando bloqueadas a mitad de campaña. La causa era la capa de cuenta: las cuentas de clientes no verificadas chocaban con el tope diario de plataforma y su ritmo cada media hora mucho antes de que el límite de la API importara, y los reposts contaban en silencio hacia el mismo presupuesto.

El arreglo de escritura fue operativo, no una migración: movieron las cuentas de alto volumen a Premium, ritmaron la publicación bajo los sub-límites cada media hora y variaron el texto reciclado para dejar de disparar el error 187. La vía de escritura se quedó en la API oficial, donde pertenece. Lo que sí se movió fue la capa de reporte intensiva en lecturas, confirmar que los posts salieron en vivo y extraer el engagement por post para los paneles de los clientes, que había estado quemando en silencio hacia el tope mensual de 2 millones de lecturas. Con precio de tarifa plana por solicitud ese trabajo de lectura sale hasta 50 veces más barato por lectura que el modelo por recurso oficial, y la factura de reporte cayó a los cientos bajos al mes mientras las restricciones de publicación se despejaron una vez que se arregló el ritmo.

Preguntas frecuentes {#faq}

¿Cuántos tweets puedes publicar por día con la API de X en 2026?

El endpoint de escritura de la API de X permite 100 posts por cada 15 minutos por usuario y 10,000 por cada 24 horas por app. El límite vinculante suele ser el tope de cuenta: desde mayo de 2026, las cuentas no verificadas están sujetas a 50 posts originales y 200 respuestas por día, ritmadas en sub-límites cada media hora, mientras que las cuentas verificadas (Premium) están exentas de estos topes publicados.

¿Cuál es el límite de tasa de la API de X para borrar tweets?

El borrado de tweets vía DELETE /2/tweets/:id está topado en 50 solicitudes por cada 15 minutos por usuario, y no hay un endpoint de borrado por lotes. A ese ritmo, limpiar 1,000 tweets toma aproximadamente cinco horas de tiempo real, repartidas a lo largo de veinte ventanas. Los trabajos de limpieza grandes lo logran construyendo estados de espera entre lotes en lugar de reintentar más rápido, porque las pausas son la API funcionando como está diseñada.

¿Se pueden publicar tweets con enlaces por la API de X, y cuánto cuesta?

Sí, pero los posts que contienen una URL se cobran a $0.20 cada uno en pago por uso a partir de la nueva tarificación del 20 de abril de 2026, contra $0.015 por un post de solo texto, más de 13 veces el costo. Un flujo que auto-publica enlaces de newsletter, posts de blog o URLs de afiliado a volumen se encarece rápido, así que el premium por URL pertenece a cualquier modelo de costo antes de lanzar una automatización de publicación pesada en enlaces.

¿El nivel gratuito de la API de X permite publicar en 2026?

No existe un nivel gratuito general para nuevos desarrolladores. X lo descontinuó cuando lanzó el pago por uso en febrero de 2026, así que las cuentas nuevas deben comprar créditos antes de publicar. El nivel gratuito legado era de solo escritura y permitía solo unos 17 posts por cada 24 horas entre toda la app, con cero acceso de lectura. Para probar lecturas en su lugar, Sorsa API incluye 100 solicitudes gratis al registrarte, sin tarjeta, cubriendo los 40 endpoints.

¿Por qué recibo un error 429 cuando estoy bajo mi límite de tasa de publicación?

Un 429 significa que se excedió una ventana de la API, pero las fallas de publicación a menudo vienen de otra capa. Los topes diarios a nivel de cuenta (50 posts originales y 200 respuestas por día para cuentas no verificadas) cuentan juntos los posts de API y manuales y suelen atar antes que el límite de la API, devolviendo típicamente un 403 o un aviso de restricción. El texto casi idéntico duplicado devuelve el error 187. Distingue los tres en lugar de tratar cada falla como un límite de tasa.

¿Cómo obtienen quienes desarrollan un alto throughput de lectura sin chocar con estos límites?

La publicación se queda en la API oficial, pero el trabajo intensivo en lecturas se mueve a una alternativa de tarifa plana para evitar las ventanas por endpoint. Sorsa API, por ejemplo, sirve los 40 endpoints de lectura a 20 solicitudes por segundo en todos los planes, desde $0.02 por cada 1,000 tweets en la base por lotes, con planes desde $49 al mes. A escala de lectura eso aterriza hasta 50 veces más barato por lectura que el precio por recurso oficial.

Cómo empezar

Si tu flujo de publicación también tiene que leer datos de X, confirmar que los posts salieron en vivo, extraer engagement para reportes o monitorear menciones tras publicar, ese lado de lectura es donde las ventanas por endpoint oficiales y el cobro por recurso más duelen, y donde una API de lectura de tarifa plana es el encaje más limpio. La forma más rápida de sentir la diferencia es correr unas cuantas llamadas tú mismo: el playground interactivo de la API ejecuta endpoints en vivo en el navegador sin clave y sin registro, así que puedes revisar la forma de la respuesta primero. Cuando estés para construir, el inicio rápido de Sorsa API te deja autenticado con una sola clave API en unos minutos, cada cuenta nueva incluye 100 solicitudes gratis (por única vez, sin tarjeta, sin vencimiento, con los 40 endpoints, suficiente para hasta 10,000 tweets o 20,000 perfiles), y los planes de tarifa plana parten de $0.02 por cada 1,000 tweets en la base por lotes, desde $49 al mes, a 20 solicitudes por segundo sin ventanas por endpoint que administrar. Escribir en X se queda en la API oficial; la mitad de lectura no tiene por qué.

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

Cómo se armó esta guía: los límites de escritura y borrado de la API, el cuerpo del 429 y las rutas de los endpoints se leyeron directo de las tablas oficiales de límites de tasa de X, y los topes de publicación a nivel de cuenta de la documentación de límites de X, ambos re-revisados el 11 de julio de 2026, porque estos números cambian sin mucho aviso y la propia página de ayuda de X todavía cita la vieja cifra de 2,400 en partes, y por eso circulan números de tope diario contradictorios; los topes de 50 posts y 200 respuestas declarados aquí se toman de la página de límites vigente. Las tácticas de ritmo de publicación y detección de duplicados, el código de recuperación del 429 y el encuadre de tres capas salen de nuestro propio trabajo operando una API de Twitter/X enfocada en lectura y de las migraciones de pipelines de lectura que maneja nuestro equipo, incluido el caso anonimizado de la agencia de arriba (detalles fusionados y despojados de cualquier cosa identificable). Las cifras de precio se resumen de nuestra cobertura separada 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 aquí está inventado.