Skip to main content
Detecta nuevas publicaciones de cuentas concretas, sigue palabras clave y alimenta tu aplicación con datos actuales de X. Esta guía explica cómo crear un flujo de supervisión casi en tiempo real con Sorsa API mediante consultas periódicas. La latencia depende del intervalo entre consultas, el tiempo de respuesta y cuándo aparece la publicación en el feed o índice elegido. Diseña el proceso con puntos de control, paginación y deduplicación: no supongas que cada publicación nueva estará en la siguiente respuesta.
Prototipos gratuitos: las primeras 100 solicitudes permiten probar todos los endpoints, sin tarjeta ni caducidad. Puedes validar la detección de publicaciones y su envío a Slack o Discord antes de elegir un plan. Las consultas periódicas consumen muchas solicitudes; dimensiona el plan con la tabla de esta guía.
Nota: consulta otras arquitecturas y ejemplos completos en la guía de supervisión con REST API.

Cómo funciona la supervisión mediante consultas periódicas

Los datos pueden llegar por envío del servidor (streaming o webhooks) o recuperarse con consultas periódicas. Sorsa utiliza este segundo método:
  1. Consulta un endpoint a intervalos regulares de 1 a 30 segundos.
  2. Compara los resultados con los IDs ya vistos.
  3. Procesa las publicaciones nuevas: guarda datos o envía alertas a Slack, Discord u otros destinos.
  4. Repite.
Los IDs codifican la fecha de creación y pueden compararse con enteros de Python o BigInt de JavaScript. El mayor ID visto sirve como punto de control, pero los resultados pueden llegar tarde o desordenados. En producción, vuelve a consultar un intervalo solapado y elimina duplicados por ID. Para recuperarte de una caída, debes guardar y cargar explícitamente el punto de control.

Elegir el endpoint


Nivel 1: Supervisar una cuenta

El bucle consulta la primera página de /user-tweets y emite publicaciones posteriores al último ID visto. En la primera consulta correcta establece el punto inicial sin emitir las publicaciones existentes. Es un ejemplo de desarrollo: puede omitir resultados si llega más de una página entre consultas o mientras el proceso está detenido.

Python

JavaScript

Este método escala mal: supervisar 50 cuentas implica 50 bucles y 50 veces más solicitudes. Para eso sirven las listas de X.

Nivel 2: Supervisar varias cuentas con una solicitud

Las listas agrupan hasta 5.000 cuentas. /list-tweets devuelve sus publicaciones recientes combinadas en una llamada. Es el patrón habitual para supervisar varias cuentas en producción. Consulta Listas y comunidades.

Paso 1: Crea una lista pública de X

  1. Abre Listas de X y crea una lista.
  2. Añade las cuentas que quieras supervisar, hasta 5.000.
  3. Establécela como pública: la API no accede a listas privadas.
  4. Copia el ID de la URL. En https://x.com/i/lists/1234567890, es 1234567890.

Paso 2: Consulta la lista

Ahorro de solicitudes. Consultar 50 cuentas por separado cada 10 segundos requiere 50 × 8.640 = 432.000 solicitudes al día. Consultar una lista con las mismas cuentas requiere 8.640: 50 veces menos. Consulta Optimización del uso de la API.
/list-tweets devuelve hasta 20 publicaciones por página. Si se publican más durante un intervalo, redúcelo a 2–3 segundos o recorre next_cursor hasta alcanzar un ID ya visto.

Nivel 3: Supervisar una palabra clave o hashtag

Consulta /search-tweets con order: "latest" para obtener coincidencias cronológicas.
Puedes utilizar los operadores de búsqueda. Por ejemplo, para seguir menciones en inglés con alta interacción y excluir retuits:

Enviar publicaciones a Slack, Discord o cualquier endpoint HTTP

El bucle produce los datos; la función de callback decide qué hacer con cada publicación. Puede enviarla a cualquier servicio HTTP.

Slack mediante Incoming Webhook

Discord

Telegram

Endpoint HTTP propio


Calcular el consumo de API

La tabla supone una página por ciclo, una frecuencia fija y ningún reintento. Multiplica por el número de procesos de supervisión y añade páginas y reintentos adicionales. Los ejemplos esperan después de recibir la respuesta, por lo que cada ciclo también incluye tiempo de red y procesamiento. Elige el intervalo según la latencia tolerable y la actividad del feed. Un intervalo menor aumenta las solicitudes, pero no garantiza que una publicación aparezca inmediatamente en la búsqueda. Las 100 solicitudes gratuitas permiten validar un prototipo completo. Para uso continuo, un bucle cada 30–60 segundos cabe en Pro (100.000 al mes) y uno cada 10 segundos en Enterprise (500.000). Son cifras por proceso; varios en paralelo multiplican el consumo. Dimensiona el plan según el volumen combinado y consulta los precios.
Para límites o volúmenes superiores, contacta con ventas o pregunta en Discord.

Preparación para producción

Los ejemplos anteriores sirven para desarrollo. En producción, resuelve estos cinco puntos.

1. Guarda last_seen_id entre reinicios

Sin un punto de control persistente, una caída puede provocar alertas duplicadas u omitir el intervalo pendiente. Guarda el último ID en un archivo, base de datos o Redis.
Sustituye last_seen_id = None por last_seen_id = load_state(). Guarda el nuevo punto de control después de procesar o encolar de forma persistente todas las páginas del ciclo. No lo avances si falla una página o entrega. Al reiniciar, recupera el intervalo pendiente antes de aceptar un punto más reciente.

2. Esperas exponenciales ante errores

Habrá fallos de red, límites HTTP 429 y errores transitorios. Aumenta gradualmente la espera hasta un máximo, en lugar de reintentar inmediatamente. Consulta Códigos de error.

3. Separa las consultas del procesamiento

No ejecutes operaciones costosas, como NLP, escrituras de base de datos o llamadas externas, de forma síncrona en el bucle. Un destino lento retrasaría las consultas. Encola las publicaciones y procésalas en otro proceso.
Para cargas mayores, sustituye la cola en memoria por Redis, RabbitMQ, SQS u otro intermediario de mensajes de tu infraestructura.

4. Supervisa el propio proceso

Registra cada ciclo: hora, nuevas publicaciones, latencia y errores. Genera una alerta si no se completa una consulta correcta durante N minutos: los fallos silenciosos provocan lagunas de datos. Consulta el estado del servicio en Sorsa Status.

5. Gestiona los casos especiales

Más de una página y resultados tardíos: recorre next_cursor hasta cubrir el intervalo desde el último punto de control. Mantén solapamiento y deduplicación para no descartar resultados tardíos por tener IDs más antiguos. Los ejemplos de primera página no implementan esta recuperación. Entrega mediante callback: comprueba el estado de respuesta del webhook y utiliza reintentos limitados o una cola persistente. Una solicitud correcta a Sorsa no significa que Slack, Discord o tu base de datos hayan aceptado el evento.
  • Publicaciones eliminadas: si se eliminan entre la consulta y el callback, su URL devolverá 404. Es un caso esperado.
  • Cuentas protegidas: si una cuenta pasa a privada, /user-tweets devuelve una lista vacía. Regístralo y continúa.
  • Publicaciones fijadas: el primer resultado puede ser el fijado, no el más reciente. No uses tweets[0] como mayor ID; calcula max(int(t["id"]) for t in tweets), como en los ejemplos, u ordena por created_at.
  • Retuits: tweet["retweeted_status"] contiene datos cuando es un retuit. Decide si incluirlos.
  • Respuestas restringidas: is_replies_limited indica restricciones del autor y puede ser una señal útil.

Próximos pasos