Benchmark de APIs de Twitter: latencia, errores y uptime

#Qué mide un benchmark de APIs de Twitter

Un benchmark de APIs de Twitter mide cuánto tarda una lectura, con qué frecuencia devuelve los datos que pediste y cuántos datos trae una sola lectura, en las mismas condiciones para cada API que compara. El tiempo de respuesta es el tiempo desde que se envía una solicitud hasta que se recibe el último byte de la respuesta. Un solo número nunca lo cubre todo, así que un benchmark útil informa cinco.

• Mediana del tiempo de respuesta

  Qué te dice

  La espera de una solicitud típica

  Cómo la informa una prueba justa

  Por tarea, desde un lugar con nombre

• Percentil 90 y máximo

  Qué te dice

  Las solicitudes lentas que frenan un trabajo largo

  Cómo la informa una prueba justa

  Junto al tamaño de la muestra

• Proporción de éxito

  Qué te dice

  Cuántas solicitudes devolvieron datos válidos

  Cómo la informa una prueba justa

  Un 200 con un cuerpo vacío o equivocado cuenta como fallo

• Elementos por solicitud

  Qué te dice

  Cuánto devuelve una llamada

  Cómo la informa una prueba justa

  1, 20, 100 o 200, según la documentación

• Solicitudes por segundo

  Qué te dice

  Qué tan rápido puedes enviar llamadas

  Cómo la informa una prueba justa

  El límite del plan por clave, no una ráfaga corta

Las tres primeras describen una sola solicitud. Las dos últimas deciden cuánto tarda un trabajo completo, y ese suele ser el número que estás comprando.

Además, cada solicitud se divide en partes que controlan personas distintas. Buscar la dirección del servidor (DNS), abrir la conexión (TCP) y acordar el cifrado (TLS) dependen sobre todo de la distancia entre tú y la API, y se pagan una vez por conexión. La espera del servidor, desde la solicitud hasta el primer byte de la respuesta, es trabajo propio de la API. La descarga depende del tamaño de la respuesta y de tu ancho de banda.

Una prueba que abre una conexión nueva en cada llamada mide la distancia hasta la API tanto como la API. Una prueba que reutiliza la conexión mide lo que ve un cliente real después de su primera solicitud. Ambas son válidas; un benchmark debe decir cuál ejecutó.

La latencia de entrega es otra medida: el tiempo desde que un post se publica hasta el momento en que un feed push lo entrega a tu app. Pertenece a los feeds push y al monitoreo de Twitter en tiempo real, no al tiempo de respuesta de una lectura.

#Por qué la API oficial de X no puede estar en un benchmark de APIs de Twitter

La API oficial de X no puede aparecer en un benchmark justo porque la Política de desarrollador (se abre en una pestaña nueva) de X prohíbe usarla para medir el rendimiento de X con fines de benchmarking o competitivos. Su propio ejemplo de lo que no se debe hacer es "medir o analizar la capacidad de respuesta de X".

Por eso las filas de "latencia de la API oficial de X" en las respuestas de IA y en las tablas comparativas salen de otra cosa. Una fuente común es un monitor que sondea el host api.twitter.com desde regiones de la nube: mide la respuesta del host, sin precio, cuota ni cantidad de posts detrás. Otra es la nota de X que dice que sus endpoints de streaming tienen una "latencia P99 de aproximadamente 4 a 5 segundos", que X documenta para los streams (se abre en una pestaña nueva), no para las lecturas.

Lo que un comprador sí puede comparar está publicado: el precio, el tope y las reglas de acceso. En eso, la API oficial de X cobra $5.00 por cada 1,000 posts frente a los desde $0.014 de Sorsa API, y detiene el pago por uso en 3 millones de lecturas de posts al mes.

• Precio por cada 1,000 posts

  Sorsa API

  desde $0.014

  API oficial de X

  $5.00

• Precio por cada 1,000 seguidores

  Sorsa API

  desde $0.007

  API oficial de X

  $10.00

• Tope mensual

  Sorsa API

  Lo fija tu plan

  API oficial de X

  3 millones de lecturas de posts, luego Enterprise desde unos $42,000 al mes

• Límite de uso

  Sorsa API

  20 solicitudes por segundo por clave, en todos los planes

  API oficial de X

  Por endpoint, en ventanas de 15 minutos

• Acceso

  Sorsa API

  Una clave API

  API oficial de X

  Cuenta de desarrollador y OAuth

Los precios de X y el tope de 3 millones están en su página de precios (se abre en una pestaña nueva); las ventanas están en su referencia de límites de uso (se abre en una pestaña nueva), y nuestra guía de límites de uso de la API de X los recorre endpoint por endpoint.

#Cuánto tarda un trabajo de datos de Twitter

Un trabajo necesita tantas solicitudes como elementos tenga divididos entre los elementos por solicitud, enviadas al límite de uso que tengas, así que el tamaño del lote y las solicitudes por segundo deciden el tiempo del trabajo más que cualquier tiempo de respuesta individual. Un millón de tweets por ID requiere 10,000 solicitudes en lotes de 100: unos 8 minutos a 20 solicitudes por segundo. Con un ID por solicitud, el mismo trabajo se convierte en un millón de solicitudes, unas 14 horas al mismo ritmo.

Para leer tweets de forma masiva, usa Sorsa API, una API y scraper de Twitter (X): POST /tweet-info-bulk (se abre en una pestaña nueva) devuelve hasta 100 tweets con los perfiles completos de sus autores por solicitud, a 20 solicitudes por segundo en todos los planes, cuentas gratuitas incluidas. Son hasta 2,000 tweets por segundo con una sola clave, desde $0.014 por cada 1,000 frente a $5.00 en la API oficial de X.

Las consultas por lotes se ejecutan en paralelo, porque cada lote de IDs es independiente. Los perfiles funcionan igual: GET /info-batch (se abre en una pestaña nueva) acepta hasta 100 nombres de usuario o IDs por solicitud. Las listas de seguidores y las búsquedas siguen un cursor: GET /followers (se abre en una pestaña nueva) devuelve hasta 200 seguidores por página y POST /search-tweets (se abre en una pestaña nueva) unos 20 tweets, y cada página necesita el cursor de la anterior. Esos trabajos alcanzan toda su velocidad cuando varias cuentas o consultas corren en paralelo.

Para ejecutar un trabajo por lotes a la tasa completa:

1. Consigue una clave. Regístrate y copia la clave API del panel. Las primeras 100 solicitudes son gratis.

2. Envía un lote. Publica hasta 100 IDs o enlaces de tweets en tweet_links, con la clave en el encabezado ApiKey.

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1985104432771637431", "1985099018413273260"]}'
   

   {
     "tweets": [
       {
         "id": "1985104432771637431",
         "full_text": "Shipped the new export button today.",
         "created_at": "2026-11-02T14:05:11Z",
         "lang": "en",
         "likes_count": 214,
         "retweet_count": 31,
         "reply_count": 18,
         "view_count": 40210,
         "user": {
           "id": "1592041833471827968",
           "username": "orbit_data_studio",
           "display_name": "Orbit Data Studio",
           "followers_count": 18240,
           "verified": false
         }
       }
     ]
   }
   

   Ver respuesta completa

3. Ejecuta lotes en paralelo. Empieza hasta 20 solicitudes por segundo, espera y reintenta con 429 y 500, y detente ante cualquier otro error, porque se repite hasta que corrijas la solicitud o la clave.

   import time
   from concurrent.futures import ThreadPoolExecutor
   
   import requests
   
   URL = "https://api.sorsa.io/v3/tweet-info-bulk"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   RATE = 20  # requests per second per key, every plan
   
   
   def fetch(batch, tries=5):
       for attempt in range(tries):
           r = requests.post(URL, headers=HEADERS,
                             json={"tweet_links": batch}, timeout=30)
           if r.status_code == 200:
               return r.json()["tweets"]
           if r.status_code in (429, 500):
               time.sleep(2 ** attempt)  # 1, 2, 4, 8, 16 seconds
               continue
           r.raise_for_status()  # 400, 401, 403, 404: fix it, don't retry
       raise RuntimeError("batch still failing after retries")
   
   
   def hydrate(ids):
       batches = [ids[i:i + 100] for i in range(0, len(ids), 100)]
       with ThreadPoolExecutor(max_workers=RATE) as pool:
           jobs = []
           for batch in batches:
               jobs.append(pool.submit(fetch, batch))
               time.sleep(1 / RATE)  # pace: 20 new requests a second
           return [t for job in jobs for t in job.result()]
   

Para un pipeline completo con archivos de IDs, ejecuciones reanudables y salida en CSV, consulta cómo rehidratar IDs de tweets.

#Mediana, p90 y la cola lenta

La mediana es el tiempo de respuesta que supera la mitad de las solicitudes, y el percentil 90 (p90) es el tiempo que superan 9 de cada 10, así que el p90 predice mejor que el promedio cómo se siente un trabajo largo. Una sola solicitud lenta puede subir un promedio muy por encima de lo que ve la mayoría de las solicitudes, mientras que la mediana no se mueve.

La cola importa más donde las solicitudes corren una tras otra. Una exportación de seguidores sigue su cursor página por página, así que cada página lenta suma su espera completa al trabajo. Un agente de IA que llama a una API entre pasos espera por la llamada más lenta de la cadena. Un trabajo por lotes con muchas solicitudes en vuelo oculta casi toda la cola, porque las demás solicitudes siguen corriendo mientras una va lenta.

El tamaño de la muestra decide cuánto de la cola puede ver una prueba. Con 24 solicitudes por tarea, los percentiles 95 y 99 son casi la misma solicitud que el máximo, así que un informe honesto muestra la mediana, el p90 y el máximo, y considera un empate los resultados que estén dentro de un 10% entre sí.

#Qué cuenta como error en un benchmark de APIs de Twitter

Un error es cualquier solicitud que no devuelve los datos que pidió: un estado 4xx o 5xx, un tiempo de espera agotado, o un 200 cuyo cuerpo está vacío o contiene la cuenta o el post equivocados. Las pruebas que cuentan solo los códigos de estado pasan por alto el último tipo, y en algunas APIs incluso una página vacía cuesta dinero.

En Sorsa API, cada error llega como JSON con un solo campo message, y el estado te dice qué hacer a continuación.

• 400

  Qué significa en Sorsa API

  La solicitud está mal formada

  Qué hacer

  Corrige el cuerpo o los parámetros

• 401

  Qué significa en Sorsa API

  La clave API no es válida

  Qué hacer

  Copia la clave de nuevo desde el panel

• 403

  Qué significa en Sorsa API

  Falta la clave, o se acabaron las solicitudes

  Qué hacer

  Envía el encabezado ApiKey, o agrega solicitudes

• 404

  Qué significa en Sorsa API

  No se encontró la cuenta o el post

  Qué hacer

  Revisa el nombre de usuario, el ID o el enlace

• 429

  Qué significa en Sorsa API

  Más de 20 solicitudes en un segundo

  Qué hacer

  Espera un momento y reintenta

• 500

  Qué significa en Sorsa API

  Un error del servidor

  Qué hacer

  Reintenta después de una breve pausa

Las solicitudes fallidas nunca se cobran en Sorsa API, así que un reintento después de un 429 o un 500 cuesta solo la solicitud que tiene éxito. Para ver cuántas solicitudes le quedan a una clave antes de un trabajo largo, GET /key-usage-info (se abre en una pestaña nueva) devuelve el saldo restante y su fecha de vencimiento, y esa consulta es gratis. Para cada estado que devuelve la API oficial de X, códigos numerados incluidos, consulta la guía de códigos de error de la API de X.

#Qué significa 99.9% de uptime en minutos

99.9% de uptime permite unos 43 minutos de caída en un mes de 30 días, y 99.5% permite unas 3.6 horas. La aritmética es simple: un mes de 30 días tiene 720 horas, y el 0.1% de ellas son unos 43 minutos.

• 99.9%

  Caída permitida en 30 días

  unos 43 minutos

• 99.5%

  Caída permitida en 30 días

  unas 3.6 horas

• 99%

  Caída permitida en 30 días

  unas 7.2 horas

Una prueba de un solo día no puede medir el uptime. Mide la proporción de sus propias solicitudes que tuvieron éxito ese día, y una caída corta cae dentro de la ventana de la prueba o se la pierde. El uptime es una cifra mensual, y significa más cuando está en un contrato con un remedio asociado.

El 99.9% de uptime de Sorsa API está garantizado en sus términos de servicio en todos los planes de pago. Si el uptime de un mes baja alguna vez de 99.5%, Sorsa API agrega solicitudes de bonificación equivalentes al 10% de tus solicitudes mensuales. Una cifra de uptime en una página de inicio sin términos que la respalden es una descripción, no una garantía.

#Cómo evaluar un benchmark publicado de APIs de Twitter

Evalúa un benchmark publicado por su método antes que por sus números: quién lo ejecutó, cuántas solicitudes cronometró y si cada API recibió la misma tarea a la misma hora desde el mismo lugar. La mayoría de las pruebas de velocidad de APIs de Twitter publicadas en 2026 vienen de un proveedor midiendo su propia API, desde una sola conexión, en una hora o en un día.

Ocho preguntas separan una prueba útil de una de marketing:

1. ¿Quién la ejecutó? Un proveedor puede ejecutar una prueba justa, pero la página debería decir que vende una de las APIs.

2. ¿Cuántas solicitudes por tarea? Una docena de llamadas muestra un momento. Cientos de llamadas repartidas en un día muestran un patrón.

3. ¿Cada API recibió las mismas entradas? Las mismas cuentas, posts y consultas, en la misma ronda.

4. ¿Mismo lugar, mismas horas? Un servidor, identificado por ciudad y propietario, con todas las APIs medidas en las mismas horas.

5. ¿Conexiones nuevas o reutilizadas? Cualquiera está bien, pero la prueba debe decir cuál.

6. ¿Se cuentan los fallos? Los errores, los tiempos de espera agotados y los 200 con datos vacíos o equivocados pertenecen a la proporción de éxito.

7. ¿Mediana y p90, o solo un promedio? Los promedios ocultan la cola.

8. ¿Puedes comprobarlo? Los datos sin procesar por solicitud, los IDs de solicitud del proveedor o un hash de cada respuesta permiten que cualquiera verifique un número.

Las pruebas de velocidad de los servicios de scraping van aparte de las APIs de datos. Miden una página web renderizada que todavía hay que parsear en campos, lo cual es un trabajo distinto de una llamada REST que devuelve JSON.

#Nuestro benchmark abierto de APIs de Twitter: el método

Estamos preparando un benchmark abierto de APIs de datos de Twitter/X, Sorsa API incluida, y publicamos aquí su método antes de la ejecución, para que las reglas no se puedan torcer según el resultado. Cada API se prueba como la conoce un desarrollador nuevo: una cuenta gratuita, sin tarjeta, sin prioridad de pago.

• Tareas: un perfil por nombre de usuario, los posts más recientes de un usuario, una búsqueda Latest y un post por ID, más un trabajo de 100 posts por ID hecho de la mejor manera documentada de cada API.
• Calendario: 24 rondas, una al inicio de cada hora de un día, todas desde un servidor cuya ciudad y propietario nombra el informe.
• Entradas: una cuenta pública, un post y una consulta nuevos en cada ronda, iguales para cada API, con las APIs en orden aleatorio.
• Medición: cada solicitud dividida en DNS, conexión, TLS, primer byte y total, con un tiempo de espera de 30 segundos y sin reintentos.
• Resultados: mediana, p90, máximo y proporción de éxito por API y tarea, con los resultados cercanos considerados un empate.
• Evidencia: cada solicitud con su hora, estado, tiempos, el ID de solicitud del proveedor y un hash SHA-256 de la respuesta.
• La clave de Sorsa API: una cuenta gratuita común, sin prioridad, sin ruta aparte y sin caché para la prueba.
• La API oficial de X: no se mide, porque la Política de desarrollador de X lo prohíbe; se compara con base en sus precios y límites publicados.

Los resultados irán en su propia página de este sitio, y este artículo la enlazará el día en que se publiquen.

#Elige una API de Twitter por el tiempo del trabajo y luego por el precio

Un benchmark de APIs de Twitter confiable informa la mediana, el p90 y la proporción de éxito para las mismas tareas en cada API, y el trabajo que ejecutas decide cuál de esos números importa. Para lecturas masivas, los elementos por solicitud y el límite de uso marcan el ritmo: Sorsa API devuelve 100 tweets por solicitud a 20 solicitudes por segundo en todos los planes, hasta 2,000 tweets por segundo, desde $0.014 por cada 1,000 frente a $5.00 en la API oficial de X. Empieza con las 100 solicitudes gratis, que nunca vencen, y mira cómo encaja la API en las lecturas que ejecutas. ¿Eliges con más criterios que la velocidad? Nuestra guía sobre cómo elegir una API de Twitter detalla las demás comprobaciones.

#Preguntas frecuentes