X (Twitter) Data Skill

La ruta de lectura determinista de datos públicos de X (Twitter) a través de UnifAPI. Esta es una Data Skill: no ejecuta por sí sola un trabajo de marketing — nombra las operaciones x/... concretas, las formas de respuesta y los gotchas para que cualquier workflow centrado en X (tarificación de KOL, vetting de creadores, señales de compra, trabajo de competencia y listening) lea desde una receta conocida en lugar de redescubrir la superficie cada vez.

Solo lectura — ojos, no manos. Investiga datos públicos de X y devuelve registros citados; nunca publica, responde, sigue ni manda DMs, y UnifAPI nunca guarda credenciales de X.

Usa la skill unifapi para obtener evidencia en vivo

Conecta una vez a través de la skill compartida unifapi (OAuth MCP), luego llama a las operaciones de abajo. La integración de X está respaldada por RapidAPI SocialLab pero el contrato público usa rutas /x/... al estilo de X — no uses las rutas legacy /twitter/.... Conserva cualquier metadato de billing para que el output pueda indicar el coste por registro.

Contrato de respuesta

Los endpoints de entidad única devuelven el objeto en data:

{
  "request_id": "unif_...",
  "data": {},
  "billing": { "records_charged": 1, "balance_remaining": 99 }
}

Los endpoints de lista devuelven un array en data más pagination:

{
  "request_id": "unif_...",
  "data": [],
  "pagination": { "has_more": false, "next_cursor": null },
  "billing": { "records_charged": 1 }
}

Cuando pagination.has_more es true, pasa pagination.next_cursor como el pagination_token de la siguiente petición (next_token también se acepta). Conserva siempre billing al reportar el coste.

Operaciones principales

¿Necesitas un campo que no está aquí? Usa el get_operation de la skill unifapi para leer el schema exacto antes de llamar — pero elige la operación de esta tabla, no descubras a ciegas.

Flujo de trabajo

Las recetas deterministas. Elige la que coincide con el trabajo; cada una nombra exactamente qué llamar.

1. Resuelve un handle a un perfil. Quita el @ inicial, luego llama a x/users/by/username/{username}. Lee data.id (necesario para cada llamada por usuario de abajo) y data.public_metrics.followers_count.
2. Lee el engagement reciente. Con el id del paso 1, llama a x/users/{id}/tweets?max_results=10&exclude=replies. Calcula el engagement a partir de las public_metrics de cada tweet (like_count, retweet_count, reply_count, quote_count, impression_count). Pagina con x/users/{id}/tweets?pagination_token={next_cursor} cuando has_more.
3. Rastrea quién amplificó un post. Con un id de tweet del paso 2, llama a x/tweets/{id}/retweeted_by, x/tweets/{id}/quote_tweets o x/tweets/{id}/liking_users para ver quién lo reposteó, citó o le dio me gusta — la señal de amplificación e intención detrás del trabajo de señales de compra, listening y competencia. Usa x/users/{id}/liked_tweets para ver con qué interactúa un usuario. Pagina vía next_cursor.
4. Mide la calidad de la audiencia. Llama a x/users/{id}/verified_followers; devuelve los seguidores verificados como una lista paginada, no una cifra lista. Mide su tamaño frente a data.public_metrics.followers_count del paso 1 — esa cuota de verificados es la señal de real-vs-inflado que alimenta la confianza y las advertencias en las skills de tarificación/vetting downstream. Pagina vía next_cursor para un recuento más completo.
5. Descubre a partir de un tema (aún sin handles). Llama a x/tweets/search/recent?query=... para posts recientes que coincidan, o x/autocomplete?query=... para sugerencias de usuario/tema, luego resuelve los handles aflorados con el paso 1.
6. Mapea una red. Llama a x/users/{id}/followers o x/users/{id}/following para trabajo de solapamiento de audiencia o de alcance; pagina vía next_cursor.
7. Lee las tendencias regionales. Llama a x/trends/by/woeid/{woeid} para ver qué es tendencia en una ubicación (WOEID), p. ej. para listening o timing de contenido.
8. Cita todo. Cada cifra se ata de vuelta al post o perfil del que proviene; reporta billing.records_charged (o estima cuando los metadatos de billing están ausentes).

Notas de forma

• XUser — métricas anidadas bajo public_metrics: followers_count, following_count, tweet_count, listed_count. Flags de perfil en el nivel superior: protected, verified, verified_type. Lee public_metrics, no los campos planos legacy.
• XTweet — métricas anidadas bajo public_metrics: like_count, retweet_count, reply_count, quote_count, bookmark_count, impression_count. Puede incluir author y media cuando estén disponibles.

Gotchas

• Usa rutas /x/..., nunca /twitter/... (legacy). El antiguo /twitter/users/{screen_name} → x/users/by/username/{username}; el antiguo /twitter/search → x/tweets/search/recent (usa x/autocomplete para descubrir usuarios/temas).
• Un timeline protegido, demasiado antiguo o demasiado escaso baja la confianza — aflóralo, no lo encubras.
• Resuelve el handle a data.id antes de cualquier llamada x/users/{id}/....
• Un saldo bajo puede truncar silenciosamente las páginas de lista: comprueba billing.truncated_due_to_balance — cuando es true la página es parcial, así que recarga antes de confiar en cualquier recuento o cuota calculado a partir de ella.

Salida

Devuelve los registros que el workflow que llama necesita, cada uno citado a su post/perfil, más una nota de coste de una línea (records_charged). Cuando esta skill se usa directamente, un resumen compacto de perfil + engagement por handle es lo predeterminado:

**@handle** — followers {N}, verified {yes/no}. Recent 10 posts: avg engagement {x}% ({likes}/{reposts}/{replies}). Evidence: {post URLs}. Records: ~{N}.

Skills relacionados

• kol-pricing, creator-shortlist, audience-fit-check (Influencer Marketing) — tarifica y vetea creadores de X sobre esta ruta de lectura.
• buying-signal-monitor (Social Selling), competitor-profiling (Competitive Intelligence), social-listening-brief (Social Listening) — trabajo de intención, competencia y listening centrado en X.
• unifapi — la skill de datos compartida: conecta MCP y consulta los schemas exactos con get_operation.