API de monitoreo de Twitter en tiempo real

#Cómo funciona el monitoreo de Twitter en tiempo real

El monitoreo de Twitter en tiempo real es un ciclo. Pide a X los posts más nuevos de un feed, conserva los que todavía no ha procesado y vuelve a pedir unos segundos después. Ese ciclo se llama sondeo (polling). El feed puede ser una cuenta, una Lista de cuentas o una búsqueda de palabras: el nombre de una marca, el usuario de un rival, un cashtag, una palabra de una caída del servicio o los analistas cuyos posts mueven un mercado.

Cada post de X lleva un ID numérico que crece con el tiempo, así que el ID más alto que has procesado funciona como punto de control: todo lo que esté por encima es nuevo. El intervalo entre consultas fija la espera más larga. Un post publicado justo después de una consulta espera un intervalo completo hasta la siguiente; uno publicado justo antes de una consulta se detecta de inmediato.

La API oficial de X funciona al revés, por envío. Su Filtered Stream mantiene abierta una conexión HTTP y envía cada post que coincide con tus reglas, y la documentación del Filtered Stream de X (se abre en una pestaña nueva) fija el retraso en unos 4 a 5 segundos para el 99% de los posts. El acceso de pago por uso permite 1 conexión, 1,000 reglas de hasta 1,024 caracteres y 250 posts por segundo, y requiere una cuenta de desarrollador aprobada, un proyecto, una app y un Bearer token.

X cobra cada post que entrega el stream como una lectura de post: $0.005, o $5.00 por 1,000, hasta 3M de lecturas de posts al mes antes de un contrato Enterprise. Desde el 22 de noviembre de 2026, un perfil de autor devuelto con un post cuesta $0.010 más, según el aviso de X del 23 de octubre (se abre en una pestaña nueva), así que un post con su autor llega a $0.015. Cada una de las demás tarifas oficiales está desglosada en la guía de precios de la API de X.

#Monitorea cuentas y palabras clave con Sorsa API

Para monitorear X desde código, usa Sorsa API, una API y scraper de Twitter (X): una solicitud lee los posts más nuevos de hasta 5,000 cuentas, los feeds por palabra clave aceptan la sintaxis de búsqueda de X y todos los planes funcionan a 20 solicitudes por segundo. Cada consulta devuelve datos frescos, cada post con el perfil completo de su autor, detrás de un solo encabezado ApiKey en lugar de una cuenta de desarrollador y OAuth.

Elige el endpoint según lo que vigiles. Cada uno devuelve una página de unos 20 posts, los más nuevos primero, y un next_cursor hacia la página anterior.

• Hasta 5,000 cuentas

  Endpoint

  GET /list-tweets (se abre en una pestaña nueva)

  Qué devuelve una solicitud

  Los posts más nuevos de cada miembro de una Lista pública

• Una cuenta

  Endpoint

  POST /user-tweets (se abre en una pestaña nueva)

  Qué devuelve una solicitud

  Sus posts, respuestas o reposts más nuevos

• Palabras, hashtags, cashtags

  Endpoint

  POST /search-tweets (se abre en una pestaña nueva)

  Qué devuelve una solicitud

  Las coincidencias más nuevas con "order": "latest"

• Posts que etiquetan a un usuario

  Endpoint

  POST /mentions (se abre en una pestaña nueva)

  Qué devuelve una solicitud

  Las menciones más nuevas, con filtros de me gusta y fecha

1. Consigue una clave. Regístrate y copia la clave de API desde tu panel. Las 100 solicitudes gratis ya están en ella.

2. Pon las cuentas en una Lista pública de X. Crea una Lista en x.com, agrega hasta 5,000 cuentas y déjala pública: ninguna clave de API puede leer una Lista privada. El ID de la Lista es el número al final de su dirección en x.com, y es el list_id que envía la solicitud de abajo.

3. Consulta la Lista. Una sola solicitud GET devuelve a la vez los posts más nuevos de todos los miembros, cada uno con el perfil de su autor.

   curl -G "https://api.sorsa.io/v3/list-tweets" \
     -H "ApiKey: YOUR_API_KEY" \
     --data-urlencode "list_id=1849722563900214388"
   

   {
     "tweets": [
       {
         "id": "2117190277605314310",
         "full_text": "Status update: EU-West checkout errors are resolved.",
         "created_at": "2026-11-02T09:41:12Z",
         "lang": "en",
         "likes_count": 14,
         "retweet_count": 5,
         "reply_count": 3,
         "quote_count": 1,
         "view_count": 2140,
         "is_reply": false,
         "conversation_id_str": "2117190277605314310",
         "user": {
           "id": "1702291101836602498",
           "username": "harborline_status_hq",
           "display_name": "Harborline Status",
           "followers_count": 48210,
           "verified": false
         }
       },
       {
         "id": "2117190206607470143",
         "full_text": "Our Q3 freight index is out: spot rates down 4%.",
         "created_at": "2026-11-02T09:40:55Z",
         "lang": "en",
         "likes_count": 31,
         "retweet_count": 9,
         "reply_count": 4,
         "quote_count": 2,
         "view_count": 5320,
         "is_reply": false,
         "conversation_id_str": "2117190206607470143",
         "user": {
           "id": "1366689741639744314",
           "username": "quaywright_analytics",
           "display_name": "Quaywright Analytics",
           "followers_count": 12904,
           "verified": true
         }
       }
     ],
     "next_cursor": "DAABCgABG3kQ8x7_7ToKAAIbeRDz9yz3QAgAAwAAAAIAAA"
   }
   

   Ver respuesta completa

4. Conserva solo los posts nuevos. Compara cada ID con tu punto de control, sigue next_cursor cuando haya llegado más de una página desde la última consulta y omite los IDs que ya procesaste. El ciclo de abajo hace las tres cosas cada 5 segundos y vuelve a revisar los IDs de los últimos 2 minutos, de modo que un post que llega tarde al feed también se atrapa.

   import time
   import requests
   
   API = "https://api.sorsa.io/v3"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   LIST_ID = "1849722563900214388"
   INTERVAL = 5              # seconds between polls
   OVERLAP = 120_000 << 22   # re-check the last 2 minutes of IDs
   
   
   def read_newer(floor):
       """Read pages until posts at or below floor show up."""
       posts, params = [], {"list_id": LIST_ID}
       for _ in range(5):  # at most 5 pages per poll
           r = requests.get(f"{API}/list-tweets", headers=HEADERS,
                            params=params, timeout=30)
           r.raise_for_status()
           page = r.json()
           tweets = page.get("tweets", [])
           newer = [t for t in tweets if int(t["id"]) > floor]
           posts += newer
           cursor = page.get("next_cursor")
           if not floor or len(newer) < len(tweets) or not cursor:
               break
           params["next_cursor"] = cursor
       return sorted(posts, key=lambda t: int(t["id"]))
   
   
   def handle(t):
       print(t["user"]["username"], t["created_at"], t["full_text"][:80])
   
   
   last_id, seen, first = 0, set(), True
   while True:
       try:
           posts = read_newer(max(last_id - OVERLAP, 0))
       except requests.RequestException as err:
           print("poll failed, retrying:", err)
           time.sleep(INTERVAL * 2)
           continue
       for t in posts:
           if t["id"] not in seen:
               seen.add(t["id"])
               if not first:  # the first poll only sets the checkpoint
                   handle(t)
           last_id = max(last_id, int(t["id"]))
       first = False
       time.sleep(INTERVAL)
   

   const API = "https://api.sorsa.io/v3";
   const headers = { ApiKey: "YOUR_API_KEY" };
   const LIST_ID = "1849722563900214388";
   const INTERVAL = 5_000;           // 5 seconds between polls
   const OVERLAP = 120_000n << 22n;  // re-check the last 2 minutes of IDs
   
   const sleep = (t) => new Promise((r) => setTimeout(r, t));
   
   async function readNewer(floor) {
     const posts = [];
     const params = new URLSearchParams({ list_id: LIST_ID });
     for (let i = 0; i < 5; i++) {
       const res = await fetch(`${API}/list-tweets?${params}`, { headers });
       if (!res.ok) throw new Error(`HTTP ${res.status}`);
       const page = await res.json();
       const tweets = page.tweets ?? [];
       const newer = tweets.filter((t) => BigInt(t.id) > floor);
       posts.push(...newer);
       if (!floor || newer.length < tweets.length || !page.next_cursor) break;
       params.set("next_cursor", page.next_cursor);
     }
     return posts.sort((a, b) => (BigInt(a.id) < BigInt(b.id) ? -1 : 1));
   }
   
   let lastId = 0n;
   let first = true;
   const seen = new Set();
   while (true) {
     try {
       const floor = lastId > OVERLAP ? lastId - OVERLAP : 0n;
       for (const t of await readNewer(floor)) {
         if (!seen.has(t.id)) {
           seen.add(t.id);
           if (!first) console.log(t.user.username, t.full_text.slice(0, 80));
         }
         if (BigInt(t.id) > lastId) lastId = BigInt(t.id);
       }
       first = false;
     } catch (err) {
       console.error("poll failed, retrying:", err.message);
       await sleep(INTERVAL);
     }
     await sleep(INTERVAL);
   }
   

5. Agrega feeds por palabra clave. Para una marca o un cashtag, consulta POST /search-tweets con "order": "latest" y pon el operador since_id: en la consulta, de modo que cada sondeo devuelva solo las coincidencias más nuevas. Los reposts nativos quedan fuera de los resultados salvo que la consulta agregue include:nativeretweets, y la guía de la API de búsqueda de Twitter lista los demás operadores.

   floor = max(last_id - OVERLAP, 0)
   query = '("lumenforge" OR #lumenforge OR $LMFG) lang:en'
   body = {"query": f"{query} since_id:{floor}", "order": "latest"}
   r = requests.post(f"{API}/search-tweets", headers=HEADERS,
                     json=body, timeout=30)
   

6. Envía cada post nuevo adonde se necesite. La función handle() es tuya para reemplazarla: escribe el post en una base de datos, publícalo en un canal de equipo en Slack o pásalo a un agente de IA que lo clasifique y lo resuma.

#Una Lista de X cubre 5,000 cuentas

Una Lista de X convierte miles de cuentas en un solo feed, y eso es lo que mantiene barato el sondeo a gran escala. Vigilar 5,000 cuentas una por una requiere 5,000 solicitudes de timeline en cada consulta. Ponlas en una sola Lista pública y cada consulta es una única solicitud a GET /list-tweets, sin importar cuántos miembros hayan publicado.

Entonces el límite de solicitudes deja de ser el cuello de botella. Sorsa API permite 20 solicitudes por segundo por clave en todos los planes, incluidas las cuentas gratuitas. Una clave puede consultar 20 Listas cada segundo, o 600 Listas que cubren hasta 3M de cuentas cada 30 segundos. En la API oficial de X, el endpoint del timeline de Listas permite 900 solicitudes por 15 minutos por app, aproximadamente una por segundo, y cobra cada post que devuelve. La guía de límites de solicitudes de la API de X trae la tabla completa.

Cada solicitud devuelve unos 20 posts. Cuando una Lista publica más que eso entre dos consultas, el ciclo de arriba sigue next_cursor hacia atrás hasta el punto de control, a una solicitud más por cada página adicional. Un intervalo más corto cumple la misma función. La lectura de los miembros y seguidores de una Lista, y la creación de Listas en bloque, se tratan en la guía de la API de Listas y Comunidades de X.

#Cada cuánto consultar y cuánto cuesta

Elige el intervalo según la espera más larga que acepta tu tarea y luego cuenta las consultas. Sorsa API cobra una solicitud por consulta, ya sea que la página contenga 20 posts nuevos o ninguno, así que el costo mensual depende de dos números: cuántos feeds consultas y con qué frecuencia. En un mes de 30 días, un feed consultado cada 30 segundos hace unas 86K solicitudes, que caben en las 100K del plan Pro. Por feed, cada intervalo resulta así:

• 5 segundos

  Solicitudes al mes

  518K

  Desde

  $726

  A la tarifa Pro

  $1,032

• 15 segundos

  Solicitudes al mes

  173K

  Desde

  $242

  A la tarifa Pro

  $344

• 30 segundos

  Solicitudes al mes

  86K

  Desde

  $121

  A la tarifa Pro

  $172

• 1 minuto

  Solicitudes al mes

  43K

  Desde

  $60

  A la tarifa Pro

  $86

• 5 minutos

  Solicitudes al mes

  8.6K

  Desde

  $12

  A la tarifa Pro

  $17

La columna "Desde" usa la tarifa más baja de Sorsa API, $1.40 por 1,000 solicitudes; la tarifa Pro es $1.99. Un feed aquí es una Lista de hasta 5,000 cuentas o una consulta de búsqueda, así que consultar 5,000 cuentas cada 30 segundos cuesta lo mismo que una. El planificador de abajo suma feeds y muestra qué plan los cubre.

Por post, un feed muy activo es donde se nota la diferencia. Una Lista o una búsqueda que llena su página de 20 en cada consulta recopila posts desde $0.07 por 1,000 en Sorsa API. La API oficial de X cobra $5.00 por 1,000 posts que entrega su stream, y $15.00 por 1,000 cuando, desde el 22 de noviembre, cobre además el autor devuelto con cada post.

Las solicitudes fallidas nunca se cobran, y GET /key-usage-info (se abre en una pestaña nueva) informa cuántas solicitudes le quedan a una clave sin gastar ninguna.

#Social listening en X con una API

El social listening en X consiste en recopilar lo que la gente publica sobre una marca, un producto o un tema, y convertirlo en números: volumen, sentimiento, alcance y las cuentas que impulsan la conversación. Una herramienta de listening lo hace dentro de su propio panel. Con una API recopilas los posts tú mismo y calculas los números en tu código, tu data warehouse o tu agente de IA.

Frente al conector de X de una herramienta de listening multired, una API de datos dedicada a X te da:

• las respuestas, citas y quienes hicieron repost de cualquier post público, completos, página por página;
• la sintaxis de búsqueda propia de X, desde frases exactas hasta lang:, min_faves: y from:;
• búsquedas sobre cualquier ventana de fechas hasta 2006, para comparar un lanzamiento con los anteriores;
• el perfil completo del autor dentro de cada post, sin una llamada adicional;
• JSON sin procesar, sin licencias por usuario ni límites de exportación, a un precio fijo por solicitud.

Las menciones de marca vienen de dos feeds: POST /mentions atrapa los posts que etiquetan tu usuario, y una búsqueda por nombre atrapa los posts que nunca lo hacen. La guía de la API de menciones de Twitter combina ambos por ID de tweet. Alrededor de cualquier post que despega, POST /comments (se abre en una pestaña nueva), POST /quotes (se abre en una pestaña nueva) y POST /retweeters (se abre en una pestaña nueva) leen las respuestas, las citas y las cuentas que lo republicaron. GET /followers (se abre en una pestaña nueva) lee una audiencia a 200 perfiles por página, GET /info-batch (se abre en una pestaña nueva) lee 100 perfiles a la vez, y GET /trends (se abre en una pestaña nueva) devuelve lo que es tendencia en un país o ciudad según su WOEID.

Las métricas que un equipo calcula a partir del feed

• Share of voice: ejecuta la misma consulta para tu marca y para cada competidor en la misma ventana y luego compara los posts coincidentes y las vistas y el alcance de seguidores que los respaldan. La guía de análisis de competidores en Twitter construye la comparación completa.
• Sentimiento: clasifica el texto de cada post como positivo, negativo o neutral con tu propio modelo o un LLM, como en nuestra guía de análisis de sentimiento en Twitter.
• Alcance y amplificación: suma view_count, retweet_count y quote_count de los posts de una ventana.
• Voces principales: ordena a los autores por followers_count y por la interacción que lograron sus posts.

Para el social listening en X desde código, Sorsa API devuelve resultados de búsqueda desde $0.07 por 1,000 con historial hasta 2006, y la misma clave ejecuta el monitor en vivo de arriba.

#Mantén el monitor confiable

Un monitor que corre durante meses se encuentra con reinicios, ráfagas y posts que llegan desordenados. Cinco hábitos evitan que pierda posts o reporte uno dos veces:

• Guarda el punto de control. Conserva el último ID en una fila de base de datos o en un archivo, para que un reinicio continúe donde se detuvo en lugar de repetir posts viejos u omitir los nuevos.
• Vuelve a revisar un traslape corto. Un post puede llegar a una Lista o a un feed de búsqueda unos segundos después de uno más nuevo. Leer hacia atrás los IDs de 2 minutos en cada consulta y omitir los IDs ya procesados atrapa esas llegadas tardías.
• Compara IDs, no posiciones. POST /user-tweets puede devolver primero el post fijado de una cuenta, así que toma el ID más alto de la página como el más nuevo.
• Retrocede ante los errores. Un 429 significa que la clave superó las 20 solicitudes por segundo: espera y reintenta. Un 403 significa que la clave no tiene solicitudes. Ninguno cuesta nada, porque las solicitudes fallidas no se cobran.
• Actualiza los contadores más tarde. Un post capturado segundos después de publicarse casi no tiene me gusta ni vistas. Vuelve a leer una hora después los posts que guardaste con POST /tweet-info-bulk (se abre en una pestaña nueva), 100 por solicitud, lo que deja los tweets conocidos desde $0.014 por 1,000.

Para tener en cuenta

El sondeo lee solo datos públicos. Las cuentas protegidas, las Listas privadas y los mensajes directos nunca aparecen en ningún feed. Sorsa API es de solo lectura por diseño: nunca publica, da me gusta ni sigue, y nunca pide tu usuario de X, así que tu propia cuenta de X no corre ningún riesgo.

#Empieza tu primer monitor en tiempo real

El monitoreo de Twitter en tiempo real se reduce a un intervalo y un punto de control: un ciclo de 5 segundos sobre una Lista pública vigila 5,000 cuentas con una solicitud por consulta. Sorsa API ejecuta ese ciclo con una sola clave de API a 20 solicitudes por segundo en todos los planes, con posts recopilados desde $0.07 por 1,000 frente a $5.00 en la API oficial de X. Pon tus cuentas en una Lista, ejecuta el ciclo de arriba con tus 100 solicitudes gratis y agrega feeds por palabra clave cuando lleguen los primeros posts.

#Preguntas frecuentes