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:- Consulta un endpoint a intervalos regulares de 1 a 30 segundos.
- Compara los resultados con los IDs ya vistos.
- Procesa las publicaciones nuevas: guarda datos o envía alertas a Slack, Discord u otros destinos.
- Repite.
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
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
- Abre Listas de X y crea una lista.
- Añade las cuentas que quieras supervisar, hasta 5.000.
- Establécela como pública: la API no accede a listas privadas.
- Copia el ID de la URL. En
https://x.com/i/lists/1234567890, es1234567890.
Paso 2: Consulta la lista
/list-tweetsdevuelve hasta 20 publicaciones por página. Si se publican más durante un intervalo, redúcelo a 2–3 segundos o recorrenext_cursorhasta alcanzar un ID ya visto.
Nivel 3: Supervisar una palabra clave o hashtag
Consulta/search-tweets con order: "latest" para obtener coincidencias cronológicas.
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.
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.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: recorrenext_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-tweetsdevuelve 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; calculamax(int(t["id"]) for t in tweets), como en los ejemplos, u ordena porcreated_at. - Retuits:
tweet["retweeted_status"]contiene datos cuando es un retuit. Decide si incluirlos. - Respuestas restringidas:
is_replies_limitedindica restricciones del autor y puede ser una señal útil.
Próximos pasos
- Operadores de búsqueda: reduce el ruido.
- Seguimiento de menciones: menciones con filtros de interacción.
- Límites de solicitudes: gestión de 429.
- Paginación: combina recuperación histórica y supervisión.
- Referencia de la API: especificaciones de los endpoints.