Conclusión clave: Los operadores de búsqueda de X son palabras clave y símbolos que filtran tweets por autor, fecha, engagement, multimedia, idioma, y ubicación. Convierten una búsqueda amplia por palabra clave en una consulta precisa, y más de 50 funcionan en la web en 2026. La API oficial de X v2 admite solo un subconjunto.

Por Sorsa Editorial

Actualizado en julio de 2026: re-verificado cada operador contra el comportamiento de búsqueda en vivo de X y la API oficial de X v2, refrescado el precio de Sorsa a las tarifas por lotes por cada 1,000 vigentes, y agregada la asignación inicial de 100 solicitudes gratis. Las revisiones anteriores agregaron la sección de operadores frecuentemente confundidos, expandieron la referencia de operadores rotos, y agregaron orientación de paginación profunda.

La mayoría de las guías se saltan calladamente la parte que más importa para el trabajo real: los operadores de mayor valor son operadores de búsqueda web que la API oficial de X v2 no admite. min_faves:, min_retweets:, la rica sintaxis de fecha since:/until:, within_time:, y filter:blue_verified funcionan todos en el cuadro de búsqueda de x.com, y todos son descartados en silencio por /2/tweets/search/recent. Sorsa API, una API alternativa de Twitter/X, pasa el conjunto completo de operadores web directo a través de su endpoint Search Tweets, así que cada operador en esta guía corre en código de producción, no solo en el sitio web. Cobra por solicitud en lugar de por recurso, corre a 20 solicitudes por segundo en todos los planes sin ventanas por endpoint, y no necesita aprobación de cuenta de desarrollador, y por eso los pipelines impulsados por operadores tienden a dejar atrás la API oficial.

Esta guía está construida para dos lectores: el especialista en marketing que quiere consultas para copiar y pegar que simplemente funcionen, y el desarrollador que necesita correr esas consultas a escala. Cada operador de abajo está agrupado por lo que filtra, con un ejemplo funcional, y el recetario los convierte en 14 patrones de consulta listos para correr.

Para dar crédito donde se debe, esta referencia se apoya en pruebas del mundo real más la referencia twitter-advanced-search mantenida por la comunidad de Igor Brigadir, la fuente de la industria de facto sobre el comportamiento de búsqueda no documentado de X.

Tabla de contenidos

  1. Cómo funcionan los operadores de búsqueda de X
  2. Operadores web vs operadores de la API oficial de X v2
  3. Palabra clave, frase, y lógica booleana
  4. Filtros de usuario y de cuenta
  5. Condicionamiento por engagement
  6. Filtros de multimedia y de tipo de contenido
  7. Fecha, hora, e IDs Snowflake
  8. Filtros geográficos
  9. Filtros de idioma y de fuente
  10. Operadores de card y de URL
  11. Operadores que la gente confunde
  12. Recetario: 14 recetas listas para producción
  13. Usar operadores con la Sorsa API
  14. Construir consultas complejas: orden de operaciones
  15. Qué está roto o es poco confiable en 2026
  16. Preguntas frecuentes

Cómo funcionan los operadores de búsqueda de X {#how-x-search-operators-work}

Los operadores de búsqueda de X son pequeños comandos de texto que agregas a una consulta para filtrar el conjunto de resultados. Funcionan en tres lugares: la barra de búsqueda de x.com, TweetDeck, y cualquier API de terceros que pase la sintaxis completa de búsqueda web, como el endpoint Search Tweets de Sorsa. La sintaxis es operator:value sin espacio alrededor de los dos puntos, y los operadores se pueden combinar libremente.

Los operadores caen en dos categorías amplias. Los operadores independientes se pueden usar por su cuenta (por ejemplo from:elonmusk devuelve un conjunto de resultados válido). Los operadores que requieren conjunción deben aparecer junto a al menos un operador independiente, porque de otro modo coincidirían con demasiado contenido. Esta distinción importa más en la API oficial de X v2 que en la web, pero vale la pena entenderla desde el inicio.

Tres reglas universales:

  • El AND es implícito. Poner dos términos uno al lado del otro (bitcoin etf) requiere ambos.
  • El OR debe ir en mayúsculas. El or en minúsculas se trata como una palabra literal.
  • La exclusión usa un guion inicial. crypto -scam quita los resultados que contienen «scam».

Si planeas usar estos en producción, guarda el Search Builder de Sorsa. Es una herramienta gratuita sin inicio de sesión que te deja alternar filtros de forma visual y genera una cadena de consulta lista para copiar con cobertura completa de operadores. Es la forma más rápida de prototipar una consulta antes de integrarla en código.


Operadores web vs operadores de la API oficial de X v2 {#web-operators-vs-official-x-api-v2-operators}

Esto es la cosa individual más importante que la mayoría de las guías no te dicen. La sintaxis de búsqueda avanzada de X que funciona en x.com es un superconjunto de la lista de operadores soportada por el endpoint de búsqueda de la API oficial de X v2. Si construyes un pipeline de producción sobre /2/tweets/search/recent y le pasas min_faves:100 since:2026-01-01 filter:blue_verified, ninguno de esos tres operadores hace nada. No son errores. Se descartan en silencio.

Hemos visto este bug exacto en varios proyectos de migración desde 2024. La consulta «funciona», en el sentido de que devuelve tweets, pero el filtrado que creías tener se fue. Para cuando alguien lo nota, el dashboard ha estado equivocado por semanas.

Aquí está la comparación operador por operador para los que a los desarrolladores realmente les importan:

Operador (sintaxis web)Funciona en x.com / SorsaFunciona en la API oficial de X v2
min_faves:N, min_retweets:N, min_replies:NNo (no soportado en absoluto)
since:YYYY-MM-DD, until:YYYY-MM-DDNo (usa los parámetros de solicitud start_time/end_time)
within_time:Xd, since_id:, max_id:No
filter:blue_verifiedNo (solo is:verified)
filter:follows, filter:socialSí (solo UI)No
filter:has_engagementNo
filter:images, filter:twimg, filter:videos, filter:native_video, filter:pro_videoParcial (solo has:media, has:images, has:video_link)
filter:spacesNo
card_name:*, card_domain:, card_url:No
near:"city", within:Xkm, geocode:Parcial (solo point_radius:, bounding_box:, place:, place_country:)
source:client_nameNo
quoted_user_id:No (solo quotes_of_tweet_id:)
filter:news, filter:safeNo
Comodín "word * word"No
from:, to:, @, #, $, url:, lang:
is:retweet, is:reply, is:quote, is:verifiedSí (con ligeras diferencias de nombre)Sí (estos son los nombres de la API v2)

Las mayores bajas para el trabajo real son los filtros de engagement (min_faves, min_retweets, min_replies) y la rica sintaxis de fecha. Sin min_faves:, no puedes hacer emerger eficientemente el contenido viral o influyente del lado de la API v2. Puedes extraer tweets y filtrar del lado del cliente, pero en consultas de alto volumen terminas quemando tu cuota en tweets que descartas de inmediato, y la diferencia de costo se acumula rápido.

Esa brecha de costo es concreta. La API oficial de X v2 cobra por recurso: una sola búsqueda que devuelve 20 publicaciones más sus perfiles de autor cuesta alrededor de $0.30 (20 lecturas de publicación a $0.005 más 20 lecturas de usuario a $0.010). La misma llamada en el plan Pro de Sorsa es una solicitud a aproximadamente $0.002, con el perfil de autor de cada tweet incluido sin cargo extra. La API oficial de X v2 también impone límites duros de caracteres en la cadena de consulta en sí, 512 caracteres para la búsqueda reciente autoservicio, 1,024 para el archivo completo, y 4,096 solo en el nivel enterprise, mientras que la sintaxis web y el paso-a-través de Sorsa están acotados solo por el tope práctico de operadores de alrededor de 22 a 23 operadores por consulta. Si necesitas publicar o enviar DMs, la API oficial sigue siendo la herramienta para eso; para leer y buscar datos públicos con el conjunto completo de operadores, una API alternativa de Twitter/X como Sorsa es la razón por la que los equipos de búsqueda impulsada por operadores cambian.

Divulgación: Sorsa es nuestro producto. Hemos mantenido esta comparación estrictamente factual; la lista de operadores faltantes es verificable contra la propia documentación pública de operadores de X el día en que este artículo se revisó. Para una mirada más profunda a las contrapartidas, consulta nuestra guía de migración desde la API oficial de X.


Palabra clave, frase, y lógica booleana {#keyword-phrase-and-boolean-logic}

Estos son los bloques de construcción. Cada consulta avanzada empieza aquí.

OperadorCon qué coincideEjemplo
keyword keywordTweets que contienen ambos términos. El espacio actúa como AND implícito.nasa esa
keyword OR keywordTweets que contienen cualquiera de los términos. OR debe ir en mayúsculas.bitcoin OR ethereum
"exact phrase"Tweets que contienen la frase exacta en ese orden. También previene la autocorrección."state of the art"
-keywordExcluye tweets que contienen el término. Funciona con frases y otros operadores.crypto -scam
( )Agrupa términos para lógica booleana compleja.(AI OR "machine learning") lang:en
"word * word"Comodín dentro de una frase entre comillas. El * reemplaza cualquier palabra individual."this is the * time"
+wordFuerza la coincidencia exacta, previniendo la autocorrección y la derivación de X.+radiooooo
#hashtagCoincide con un hashtag específico.#tgif
$cashtagCoincide con un símbolo de acción o de cripto.$TSLA

Unas cuantas notas prácticas que hacen tropezar a la gente. Los plurales coinciden con sus singulares y viceversa: bulls coincidirá con bull. X a veces reinterpreta en silencio las palabras comunes como intención de contenido, así que buscar photo puede devolver tweets con imágenes adjuntas incluso cuando la palabra «photo» está ausente del texto; envuelve esas palabras entre comillas dobles para forzar una coincidencia literal. Los operadores tampoco están estrictamente atados al cuerpo del tweet: pueden coincidir contra el nombre para mostrar del autor, el nombre de usuario, y las URLs expandidas dentro del tweet, lo que es una fuente frecuente de resultados sorprendentes.

El tope en el conteo de operadores es real. Una vez que cruzas aproximadamente 22 a 23 operadores en una sola consulta, X empieza a ignorar las partes finales de la cadena en silencio. Si necesitas más que eso, parte en varias llamadas a la API y fusiona los resultados posteriormente.


Filtros de usuario y de cuenta {#user-and-account-filters}

Estos filtran tweets por quién publicó, a quién responden, o quién es mencionado.

OperadorDescripciónEjemplo
from:usernameTweets enviados por una cuenta específica (sin la @).from:elonmusk
to:usernameTweets que son respuestas a una cuenta específica.to:openai
@usernameTweets que mencionan una cuenta específica en cualquier parte del texto.@sorsa_app
list:IDTweets de los miembros de una Lista pública de X. Usa el ID numérico de la Lista de la URL.list:715919216927322112
filter:verifiedSolo de cuentas verificadas legadas (palomitas azules previas a 2023).AI filter:verified
filter:blue_verifiedSolo de suscriptores de X Premium (Blue de pago).crypto filter:blue_verified
filter:followsSolo de cuentas que sigues. Solo UI, no se puede negar.filter:follows
filter:socialDe tu red expandida algorítmicamente. Funciona en resultados «Top», no en «Latest».filter:social

Truco de monitoreo de marca. Combina @ o un nombre de marca entre comillas con -from: para encontrar lo que todos excepto la marca misma dicen de la marca: "Tesla" -from:tesla. Ese solo movimiento es la diferencia entre señal accionable y ruido de PR, y es la columna vertebral de la mayoría de las configuraciones de escucha social.

Para un tratamiento más profundo del monitoreo de menciones, consulta los docs sobre rastrear menciones; el operador list: se empareja naturalmente con la API de Listas de X cuando quieres los tweets de cada miembro en un solo feed.


Condicionamiento por engagement {#engagement-gating}

Filtra por engagement mínimo (o máximo). Estos son esenciales para cortar a través del ruido y hacer emerger el contenido viral, y también son los operadores que más a menudo faltan en la API oficial de X v2.

OperadorDescripciónEjemplo
min_faves:NNúmero mínimo de likes.AI min_faves:100
min_retweets:NNúmero mínimo de retweets.crypto min_retweets:50
min_replies:NNúmero mínimo de respuestas."product launch" min_replies:20
-min_faves:NLikes máximos (forma negada).bitcoin -min_faves:1000
-min_retweets:NRetweets máximos.news -min_retweets:500
-min_replies:NRespuestas máximas.tech -min_replies:100
filter:has_engagementTweets con al menos una interacción. Se puede negar para encontrar tweets de cero engagement.from:username filter:has_engagement

Cómo fijar los umbrales. Empieza bajo (min_faves:10) e incrementa de forma iterativa. Los reportes de X se vuelven aproximados por encima de aproximadamente 1,000, así que no sobre-ajustes. Combina con -filter:retweets si solo quieres tweets que se ganaron el engagement por su propio contenido en lugar de a través de la amplificación. En nuestro propio trabajo de pipeline, la combinación min_faves:N más -filter:retweets más -filter:replies es el filtro individual más útil para hacer emerger contenido viral original; todo lo demás es adorno.


Filtros de multimedia y de tipo de contenido {#media-and-content-type-filters}

X tiene un control inusualmente granular sobre qué tipo de contenido aparece en tus resultados. La trampa es que el conjunto de operadores web es mucho más rico que los equivalentes de la API v2.

Filtros de multimedia

OperadorDescripción
filter:mediaTodos los tipos de multimedia (imágenes, video, GIFs).
filter:imagesTodas las imágenes, incluidos los enlaces de terceros (por ejemplo, Instagram).
filter:twimgSolo imágenes nativas de X (enlaces pic.twitter.com).
filter:videosTodos los tipos de video: video nativo de X, embeds de YouTube, y demás.
filter:native_videoSolo video propiedad de X (subidas nativas, Vine legado, Periscope legado).
filter:consumer_videoSolo video nativo de X (excluye pro/Amplify).
filter:pro_videoSolo video pro de X (Amplify).
filter:spacesContenido de audio de X Spaces.
filter:linksTweets que contienen cualquier URL. Incluye URLs de multimedia; usa -filter:media para aislar los enlaces sin multimedia.
card_name:animated_gifCoincide específicamente con GIFs.

Filtros de tipo de tweet

OperadorDescripción
filter:repliesSolo tweets que son respuestas a otro tweet.
-filter:repliesExcluye respuestas (muestra solo tweets originales de nivel superior).
filter:nativeretweetsSolo retweets nativos (creados vía el botón de retweet).
include:nativeretweetsIncluye retweets nativos en los resultados (se excluyen por defecto).
filter:retweetsRetweets de estilo viejo RT más tweets citados.
-filter:retweetsExcluye retweets por completo.
filter:quoteSolo tweets citados.
quoted_tweet_id:IDCitas de un tweet específico por su ID.
quoted_user_id:IDTodas las citas de un usuario específico por su ID de usuario.
conversation_id:IDTodos los tweets en un hilo (respuestas directas y respuestas anidadas).

Filtros de contenido especial

OperadorDescripción
card_name:poll2choice_text_onlyTweets que contienen encuestas de texto de 2 opciones.
card_name:poll3choice_text_onlyEncuestas de texto de 3 opciones.
card_name:poll4choice_text_onlyEncuestas de texto de 4 opciones.
card_name:poll2choice_imageEncuestas de imagen de 2 opciones.
filter:newsTweets que enlazan a dominios de noticias reconocidos.
filter:safeExcluye contenido NSFW o potencialmente sensible. No es una garantía.
filter:hashtagsSolo tweets que contienen al menos un hashtag.
filter:mentionsSolo tweets que contienen cualquier @mención.

Fecha, hora, e IDs Snowflake {#date-time-and-snowflake-ids}

El filtrado preciso basado en tiempo es crítico para el análisis de eventos, el rastreo de campañas, y la extracción de datos históricos. Este es también el lugar donde la API oficial de X v2 diverge más marcadamente: espera start_time y end_time como parámetros de solicitud separados y no entiende since: / until: en la cadena de consulta. La sintaxis web y Sorsa admiten el conjunto completo.

OperadorFormatoDescripción
since:YYYY-MM-DDsince:2026-01-01Tweets publicados en o después de esta fecha (inclusivo).
until:YYYY-MM-DDuntil:2026-03-01Tweets publicados antes de esta fecha (no inclusivo).
since:YYYY-MM-DD_HH:MM:SS_UTCsince:2026-03-05_12:00:00_UTCMarca de tiempo de precisión con zona horaria.
since_time:UNIXsince_time:1142974200Después de una marca de tiempo Unix específica (en segundos).
until_time:UNIXuntil_time:1142974215Antes de una marca de tiempo Unix específica.
within_time:Xdwithin_time:2dDentro de los últimos X días. También admite h (horas), m (minutos), s (segundos).
since_id:IDsince_id:1234567890Después de un ID Snowflake específico (no inclusivo).
max_id:IDmax_id:1234567890En o antes de un ID Snowflake específico (inclusivo).

El truco del ID Snowflake

Cada ID de tweet en X es un ID Snowflake que codifica su marca de tiempo de creación con precisión de milisegundo. La fórmula de conversión:

text
millisecond_epoch = (tweet_id >> 22) + 1288834974657

Esto es útil por dos razones. Primero, puedes calcular la hora exacta de publicación de cualquier tweet sin hacer una llamada a la API, lo que es práctico para los trabajos de backfill que deduplican u ordenan por tiempo. Segundo, since_id: y max_id: te dan límites a nivel de tweet en lugar de a nivel de fecha en las ventanas de resultados, lo que es invaluable cuando estás paginando una palabra clave de alto volumen durante horas y quieres reanudar exactamente donde te quedaste sin volver a obtener tweets que ya viste.

Para un recorrido más profundo de extraer conjuntos históricos de tweets, consulta nuestra guía sobre buscar tweets viejos.


Filtros geográficos {#geographical-filters}

Una revisión de realidad antes de que profundices aquí: solo un estimado de 1 a 2 por ciento de los tweets cargan datos de geolocalización precisos. X quitó el etiquetado de ubicación precisa de las apps principales de iOS y Android en junio de 2019, y la mayoría de los usuarios nunca optaron por él para empezar. Los filtros de geo siguen siendo útiles, pero espera cobertura delgada.

OperadorDescripciónEjemplo
near:"city"Geoetiquetado cerca de un lugar nombrado. Admite frases.near:"San Francisco"
near:meCerca de tu ubicación actual (solo UI).near:me
within:XkmLímite de radio para near:. Acepta km o mi.earthquake near:Tokyo within:50km
geocode:lat,long,radiusPrecisión exacta usando coordenadas.geocode:37.77,-122.41,5km
place:IDBusca por ID de X Place Object.place:96683cc9126741d1 (USA)

Del lado de la API estructurada, la API oficial de X v2 usa un conjunto de geo diferente, place_country:, point_radius:, y bounding_box:, en lugar de los operadores web near:/within:/geocode:. Sorsa acepta los operadores de geo web a través de su campo query, los mismos que funcionan en el cuadro de búsqueda de x.com; las formas de la API v2 se muestran en la tabla de comparación de arriba.

Un comportamiento de respaldo útil. Si un tweet no tiene coordenadas precisas, la búsqueda recurre a la geocodificación inversa de la ubicación del perfil del usuario, así que puedes recibir tweets que coinciden con base en la ubicación declarada del autor en lugar del origen real del tweet. Eso es a veces lo que quieres y a veces confuso. Para un enfoque de mayor cobertura para mapear dónde se basa una audiencia, consulta geografía de audiencia por país.


Filtros de idioma y de fuente {#language-and-source-filters}

Idioma

X usa códigos ISO 639-1 de 2 letras: lang:en, lang:es, lang:fr, lang:de, lang:ja, lang:ru, y demás. También hay varios códigos no estándar que vale la pena conocer:

CódigoSignificado
lang:undIdioma indefinido (tweets de solo emoji o de solo multimedia).
lang:qmeTweets con solo enlaces de multimedia (desde 2022).
lang:qstTweets de texto muy corto.
lang:qhtTweets con solo hashtags.
lang:qamTweets con solo menciones.
lang:qctTweets con solo cashtags.
lang:zxxTweets con solo multimedia o una Twitter Card, sin texto adicional.

Un uso de alta señal: from:user lang:zxx filter:images devuelve tweets que son una imagen y nada más, con cero ruido de texto. La detección de idioma de X no es perfecta, sin embargo. Los tweets cortos, los fragmentos de código, y las publicaciones cargadas de emoji se clasifican mal rutinariamente, así que para aplicaciones críticas corre tu propia detección de idioma sobre el texto del cuerpo después de la recuperación.

Fuente (cliente de publicación)

OperadorDescripciónEjemplo
source:client_nameFiltra por la app usada para publicar. Usa guiones bajos para los espacios.source:Twitter_for_iPhone

Valores comunes: Twitter_for_iPhone, Twitter_for_Android, Twitter_Web_App, TweetDeck, twitter_ads. Nota que source: a veces necesita otro operador junto a él para devolver resultados.


Operadores de card y de URL {#card-and-url-operators}

Estos coinciden con los metadatos de Twitter Card: las vistas previas ricas adjuntas a los tweets que contienen enlaces, multimedia, y contenido incrustado. Dos cosas que hay que saber de entrada: card_name: típicamente solo funciona para tweets de los últimos 7 a 8 días, y url: funciona bien para dominios pero es poco confiable para las rutas de URL largas.

OperadorDescripción
card_domain:domainCoincide con el nombre de dominio en una Twitter Card. Mayormente equivalente a url:.
card_url:domainSimilar a card_domain: pero puede devolver resultados diferentes.
card_name:audioTweets con Player Cards (Spotify, SoundCloud, y demás).
card_name:playerTweets con cualquier Player Card.
card_name:summaryCards de resumen de imagen pequeña.
card_name:summary_large_imageCards de resumen de imagen grande.
card_name:promo_websiteCards de sitio web promocionadas (usualmente publicadas vía Ads).
card_name:promo_image_convoCards de anuncio conversacional con imágenes.
card_name:promo_video_convoCards de anuncio conversacional con video.
url:domainCoincide con URLs. Funciona bien para dominios y subdominios. Los guiones deben reemplazarse con guiones bajos (por ejemplo, url:t_mobile.com).

Operadores que la gente confunde {#operators-people-mix-up}

Un puñado de operadores se ven intercambiables y no lo son. Estos son los pares que calladamente corrompen un dataset, así que vale la pena ser preciso sobre cada uno.

filter:verified vs filter:blue_verified. filter:verified coincide con cuentas que tenían verificación legada (periodistas, figuras públicas, organizaciones verificadas antes de 2023). filter:blue_verified coincide con cualquiera suscrito a X Premium de pago. La mayoría de las consultas de monitoreo de marca y editoriales quieren filter:verified para señal, no filter:blue_verified, que incluye a cualquier usuario que paga. Para aislar las cuentas legadas de forma limpia, combínalos: filter:verified -filter:blue_verified.

-filter:retweets vs include:nativeretweets vs -is:retweet. -filter:retweets (sintaxis web) excluye tanto los retweets de texto de estilo viejo «RT» como los retweets nativos. include:nativeretweets agrega los retweets nativos de vuelta a un conjunto de resultados que los excluye por defecto. -is:retweet es la ortografía de la API oficial de X v2 para excluir retweets, y es más estrecha que filter:retweets, que históricamente también barría los tweets citados. Para un conjunto limpio de contenido original del lado web, usa -filter:retweets; para rastrear qué tan lejos se propagó un tweet, usa filter:nativeretweets con una ventana de tiempo ajustada.

within_time:Xd vs since:/until:. within_time:7d es una ventana deslizante medida desde el momento en que corre la consulta, así que la misma consulta devuelve un conjunto de tweets diferente mañana del que devuelve hoy. since: y until: son límites de calendario fijos. Para datasets de investigación reproducibles, siempre prefiere las fechas since:/until: explícitas sobre within_time:.

from:user vs @user. from:user devuelve solo los tweets escritos por esa cuenta. @user devuelve cualquier tweet que mencione la cuenta, incluidas respuestas y tweets citados de otras personas. Usa from: para el análisis de cronología y @ para el monitoreo de menciones; en usuarios de palabra común, agrega lang:en o un pequeño piso de engagement a las consultas @ para cortar el ruido.

filter:retweets vs -is:retweet. filter:retweets es sintaxis web que coincide con los retweets; -is:retweet es la sintaxis de la API v2 para excluirlos. No son inversos perfectos, así que para excluir cada forma de amplificación del lado web, empareja -filter:retweets con -filter:quote.

Estos operadores filtran tweets por tipo de interacción. Recuperar las respuestas, citas, y retweeters reales detrás de un tweet dado es un trabajo separado, manejado por endpoints dedicados y cubierto en la guía de la API de engagement de Twitter.


Recetario: 14 recetas listas para producción {#cookbook-14-production-ready-recipes}

Los operadores son útiles de forma aislada. Son poderosos en combinación. Aquí hay catorce patrones de consulta que hemos construido nosotros mismos o visto en pipelines de clientes. Cópialos, cambia las variables, y pégalos directo en la barra de búsqueda de X o en el endpoint de búsqueda de Sorsa.

1. Monitoreo de marca y de reputación

Encuentra contenido viral original sobre una marca, excluyendo las propias publicaciones de la marca y el ruido de retweets:

text
("Tesla" OR "Elon Musk") min_faves:500 filter:links lang:en -from:tesla -filter:nativeretweets

2. Generación de leads de competencia

Encuentra usuarios que activamente preguntan por alternativas en tu nicho:

text
("notion" OR "obsidian") "?" -filter:links -from:notionhq lang:en

3. Descubrimiento de compradores de alta intención

Encuentra tweets que se leen como señales de compra para una categoría de producto:

text
("looking for" OR "anyone use" OR "recommend") ("twitter api" OR "x api") -filter:retweets lang:en

4. Descubrimiento de influencers

Publicaciones originales de alto engagement de cuentas verificadas en un tema:

text
"machine learning" filter:blue_verified min_faves:200 -filter:replies -filter:retweets lang:en

5. OSINT y noticias de última hora

Rastrea eventos en tiempo real con evidencia visual de fuentes verificadas:

text
"breaking news" filter:images filter:blue_verified within_time:6h

6. Curaduría de contenido desde Listas de X

Encuentra videos virales publicados por los miembros de una Lista específica:

text
list:715919216927322112 (filter:videos OR card_name:animated_gif) min_retweets:50

7. Resolución de problemas de desarrolladores

Encuentra conversaciones relacionadas con errores que enlazan a GitHub:

text
url:github.com "error" lang:en filter:replies

8. Sentimiento cripto con condicionamiento por engagement

Rastrea la conversación cargada de sentimiento sobre un token, filtrada por sustancia:

text
(bitcoin OR $BTC) (bullish OR bearish OR crash OR moon) min_faves:20 lang:en since:2026-01-01 -filter:retweets

9. Monitoreo hiperlocal

Qué se está diciendo cerca de un lugar específico en una ventana de tiempo ajustada:

text
"traffic" near:"London" within:5km since:2026-03-05_12:00:00_UTC

10. Encontrar tweets citados de un usuario específico

Coincide con el patrón de la forma de la URL y excluye el propio usuario del usuario:

text
twitter.com/elonmusk/status/ -from:elonmusk

11. Líderes de hilo solo originales

Encuentra tweets que iniciaron hilos (no respuestas, no retweets) y se ganaron engagement real:

text
"your topic" min_replies:10 -filter:replies -filter:retweets lang:en

12. Rastrear una ventana de lanzamiento de producto

Captura toda la conversación en un rango de fecha específico con un piso de engagement:

text
"product name" since:2026-02-10 until:2026-02-17 lang:en min_faves:5

13. Detección de spam de cero engagement

Identifica la publicación sospechosa de baja calidad (útil para los pipelines de moderación):

text
"buy now" -filter:has_engagement filter:links lang:en

14. Minería de bolsas de trabajo

Tweets con señal de contratación en un nicho técnico específico:

text
("hiring" OR "we're looking for") ("react" OR "typescript") -filter:retweets lang:en min_faves:5

El patrón a lo largo de las catorce: empieza con el tema, superpón engagement, superpón tipo de contenido, luego superpón exclusiones. Las exclusiones son usualmente lo que separa un conjunto de resultados ruidoso de uno usable.


Usar operadores con la Sorsa API {#using-operators-with-the-sorsa-api}

Cada operador listado arriba funciona en el campo query del endpoint /v3/search-tweets de Sorsa. Pasa tu cadena de consulta completa en el cuerpo de una solicitud POST, pagina vía next_cursor, y maneja los 429 con un breve reintento. Para el flujo de trabajo más amplio alrededor del orden, la paginación, y el manejo de resultados, la guía para buscar tweets por API lo recorre de principio a fin.

Una llamada mínima con curl:

bash
curl -X POST https://api.sorsa.io/v3/search-tweets \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "(AI OR \"machine learning\") min_faves:100 lang:en -filter:retweets",
    "order": "popular"
  }'

Python: listo para producción con paginación y reintento

Este es el patrón que corremos en producción. Pagina el conjunto completo de resultados, reintenta ante el límite de tasa, y hace emerger los errores duros:

python
import requests
import time
from typing import Iterator

API_KEY = "YOUR_SORSA_API_KEY"
BASE_URL = "https://api.sorsa.io/v3/search-tweets"


def search_tweets(query: str, order: str = "latest") -> Iterator[dict]:
    """
    Paginate through every tweet matching the query.
    Retries on 429 (rate limit) with a 1-second wait.
    """
    cursor = None
    while True:
        payload = {"query": query, "order": order}
        if cursor:
            payload["next_cursor"] = cursor

        response = requests.post(
            BASE_URL,
            headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
            json=payload,
            timeout=30,
        )

        if response.status_code == 429:
            time.sleep(1.0)
            continue

        response.raise_for_status()
        data = response.json()

        for tweet in data.get("tweets", []):
            yield tweet

        cursor = data.get("next_cursor")
        if not cursor:
            break


# Usage: collect viral AI tweets from January 2026
for tweet in search_tweets(
    '(AI OR "machine learning") min_faves:1000 lang:en '
    'since:2026-01-01 until:2026-02-01'
):
    print(tweet["id"], tweet["likes_count"], tweet["full_text"][:80])

JavaScript / Node.js: patrón de iterador async

javascript
const API_KEY = "YOUR_SORSA_API_KEY";
const BASE_URL = "https://api.sorsa.io/v3/search-tweets";

async function* searchTweets(query, order = "latest") {
  let cursor = null;

  while (true) {
    const payload = { query, order };
    if (cursor) payload.next_cursor = cursor;

    const res = await fetch(BASE_URL, {
      method: "POST",
      headers: { ApiKey: API_KEY, "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    });

    if (res.status === 429) {
      await new Promise((r) => setTimeout(r, 1000));
      continue;
    }
    if (!res.ok) throw new Error(`Sorsa API error: ${res.status}`);

    const data = await res.json();
    for (const tweet of data.tweets ?? []) yield tweet;

    cursor = data.next_cursor;
    if (!cursor) break;
  }
}

// Usage
for await (const tweet of searchTweets(
  '"product launch" min_faves:50 lang:en since:2026-02-10'
)) {
  console.log(tweet.id, tweet.likes_count);
}

La paginación profunda es poco confiable: mejor trocea por fecha

Una cosa que hay que planear en cualquier extracción histórica de alto volumen: la paginación de búsqueda de X es inestable para los conjuntos de resultados profundos. Este es un comportamiento de la plataforma upstream que cada camino de acceso hereda, no una peculiaridad de una API. Pasada aproximadamente la primera docena de páginas de una sola cadena de cursor, empiezas a ver duplicados o la cadena se detiene temprano, mucho antes de que el conjunto de resultados se agote.

El arreglo es dejar de depender de una sola cadena de cursor larga y partir la consulta en trozos por rango de fechas en su lugar. Corre varias consultas más pequeñas, cada una acotada por since: y until:, y pagina cada trozo en su propio cursor fresco:

python
from datetime import date, timedelta


def chunked_search(query_base: str, start: date, end: date, chunk_days: int = 7):
    """Split a long date range into weekly chunks, each with its own cursor chain."""
    current = start
    while current < end:
        chunk_end = min(current + timedelta(days=chunk_days), end)
        full_query = (
            f"{query_base} since:{current.isoformat()} until:{chunk_end.isoformat()}"
        )
        yield from search_tweets(full_query, order="latest")
        current = chunk_end


# Q1 2026, week by week, no deep-cursor instability
for tweet in chunked_search(
    'openai min_faves:200 lang:en', date(2026, 1, 1), date(2026, 4, 1)
):
    print(tweet["id"])

Para eventos de movimiento rápido donde incluso una semana es demasiado ancha, baja a trozos por hora usando la forma completa de marca de tiempo (since:2026-03-01_12:00:00_UTC until:2026-03-01_13:00:00_UTC). Cada trozo es reproducible y reanudable, lo que importa cuando estás reconstruyendo la cronología de un lanzamiento o de un evento noticioso. Para los pipelines de archivado que necesitan tomar una instantánea de tweets específicos en lugar de buscarlos, el endpoint tweet-info-bulk toma hasta 100 IDs de tweet por solicitud.


Construir consultas complejas: orden de operaciones {#building-complex-queries-order-of-operations}

Una vez que empiezas a apilar cinco o seis operadores, el orden en que se evalúan empieza a importar. La regla en X es la misma que en la mayoría de los motores de búsqueda: el AND se enlaza más fuerte que el OR.

Eso significa que cat OR black dog se evalúa como cat OR (black dog), no como (cat OR black) dog. Si quieres la segunda interpretación, usa paréntesis: (cat OR black) dog. Ante la duda, usa paréntesis. No te cuestan nada y eliminan la ambigüedad.

Un orden de construcción que funciona para casi cada consulta:

  1. Agrupa las palabras clave centrales entre paréntesis: (bitcoin OR ethereum OR $BTC)
  2. Agrega restricciones de contenido: lang:en, filter:images, -filter:replies
  3. Fija los umbrales de engagement: min_faves:50, min_retweets:10
  4. Excluye el ruido: -from:spambot, -scam, -airdrop, -filter:retweets
  5. Agrega límites de tiempo si se necesita: since:2026-01-01 until:2026-03-01

Sigue este orden de forma consistente y podrás leer cualquiera de tus consultas de un vistazo y detectar errores más rápido.


Qué está roto o es poco confiable en 2026 {#what-is-broken-or-unreliable-in-2026}

Los operadores fallan calladamente en X. La consulta todavía devuelve tweets, así que un filtro roto se ve como uno funcional hasta que los datos ya están mal. Estos son los modos de falla que vale la pena conocer antes de que muerdan.

Operadores que ya no se comportan como sus nombres sugieren:

OperadorEstado en 2026Por qué
filter:vineSolo históricoVine cerró en 2017; coincide solo con contenido archivado previo a 2017.
filter:periscopeSolo históricoPeriscope cerró en 2021.
near:, within:, geocode:Cobertura reducidaEl geoetiquetado preciso se quitó de las apps de iOS y Android en junio de 2019; solo 1 a 2 por ciento de los tweets cargan coordenadas.
filter:nativeretweetsAproximadamente 7 a 10 díasX retiene los datos de retweet nativo solo a corto plazo.
card_name:*, card_domain:Aproximadamente 7 a 8 díasLos metadatos de card tienen retención corta.
filter:verifiedInconsistenteLa verificación legada y el Blue de pago se confundieron tras el rebrand de 2023; usa filter:verified -filter:blue_verified para aislar las cuentas legadas.

Situaciones comunes de «mi búsqueda no funciona» y qué está pasando en realidad:

  • Estás en «Top» en lugar de «Latest». La pestaña Top por defecto muestra una selección algorítmica y esconde la mayoría de las coincidencias, lo que se lee como resultados faltantes. Cambia a la pestaña Latest, o pasa order: "latest" en la API, para cobertura completa.
  • Una búsqueda de frase exacta entre comillas no devuelve nada. Las comillas fuerzan una coincidencia de token exacta y deshabilitan la corrección ortográfica, así que una frase para la que X no tiene coincidencia exacta regresa vacía. Quita las comillas, o usa la forma comodín "word * word", para aflojarla.
  • from: no devuelve nada o basura. La causa más común es un espacio después de los dos puntos: escribe from:username, nunca from: username, ya que el espacio rompe el operador. La segunda causa más común es un rango de fecha durante el cual la cuenta no publicó.
  • geocode: o near: no devuelve casi nada. La cobertura de geo colapsó después de 2019; para el trabajo de ubicación, apóyate en el respaldo de ubicación de perfil o analiza dónde se basa una audiencia por país en lugar de las coordenadas a nivel de tweet.
  • La consulta funcionó en x.com pero no en la API oficial de X v2. Casi siempre un operador solo-web que la API descarta en silencio; consulta la tabla de comparación web versus API v2 de arriba.

Unas cuantas trampas más duraderas:

  • Tope de operadores: las consultas admiten aproximadamente 22 a 23 operadores. Cruza eso y la parte final de la consulta se ignora en silencio.
  • Las cuentas privadas y suspendidas están excluidas de todos los resultados de búsqueda; ninguna combinación de operadores las alcanza.
  • No todos los tweets están indexados. Las publicaciones marcadas por razones de plataforma o anti-spam están excluidas de la búsqueda incluso cuando técnicamente siguen vivas. Este es un hueco conocido al perseguir cuentas con engagement bloqueado (consulta nuestro escrito sobre el error «this request looks like it might be automated» de Twitter para contexto relacionado).
  • La autocorrección ocurre en silencio en algunos casos; usa +word o "word" para forzar la coincidencia exacta.
  • La coincidencia de URL es frágil. Los dominios y subdominios funcionan, las rutas de URL largas no, y los guiones en los dominios deben reemplazarse con guiones bajos (url:t_mobile.com).

En la práctica

Un equipo de analítica social de unas 12 personas con el que trabajamos había construido un dashboard de monitoreo de marca sobre la API oficial de X v2. Su consulta usaba min_faves: y filter:blue_verified para hacer emerger solo las menciones de alta señal que valían una respuesta humana. En la API v2, ambos son operadores solo-web que se descartan en silencio, así que por semanas el panel de «menciones top» estuvo ingiriendo cada mención de bajo engagement y la priorización era efectivamente aleatoria. Nadie vio un error, porque no había ninguno. Mover la misma cadena de consulta a una API de búsqueda que acepta el conjunto completo de operadores web lo arregló sin reescribir ninguna lógica de filtro, y como el cobro es por solicitud en lugar de por recurso, el mismo volumen de monitoreo costó una fracción pequeña del precio oficial por lectura de publicación. La falla era invisible precisamente porque los operadores que se rompieron eran los que la API oficial nunca admitió en primer lugar.


Preguntas frecuentes {#faq}

¿Qué es la búsqueda avanzada de X?

La búsqueda avanzada de X es la forma integrada de la plataforma de filtrar tweets por autor, fecha, engagement, tipo de multimedia, idioma, y ubicación. Está disponible como un formulario en x.com/search-advanced, o puedes escribir los mismos operadores directamente en la barra de búsqueda desde cualquier lugar. Una vez que conoces la sintaxis, escribir operadores es más rápido que llenar el formulario.

¿Cómo busco en Twitter por fecha?

Para buscar en Twitter por fecha, combina since:YYYY-MM-DD y until:YYYY-MM-DD en una consulta, por ejemplo "product launch" since:2026-02-10 until:2026-02-17. La fecha since: es inclusiva y la fecha until: es exclusiva, así que el tweet debe publicarse antes de la fecha until, no en ella. Para precisión de menos de un día, usa la forma de marca de tiempo since:2026-02-10_14:00:00_UTC.

¿Por qué no funciona mi operador de búsqueda en la API oficial de X?

Los operadores como min_faves:, min_retweets:, since:, until:, within_time:, filter:blue_verified, y card_name: son operadores de búsqueda web que la API oficial de X v2 no admite; los ignora en silencio en lugar de devolver un error. El endpoint de búsqueda de Sorsa acepta el conjunto completo de operadores web, y por eso los equipos que corren pipelines filtrados por engagement o acotados por fecha se mueven fuera de la API oficial.

¿Cómo encuentro tweets viejos sin una cuenta de X?

X requiere inicio de sesión para la mayoría de la búsqueda en 2026, incluida la barra de búsqueda básica. Dos opciones funcionan sin tu propia cuenta: la Wayback Machine del Internet Archive para URLs de tweet específicas que ya tengas, o una API de Twitter/X de terceros que mantenga su propio acceso al índice de búsqueda público, como Sorsa, que devuelve resultados históricos como JSON estructurado.

¿Cuál es la diferencia entre filter:retweets y -is:retweet?

filter:retweets es sintaxis de búsqueda web que coincide con los retweets, mientras que -is:retweet es la sintaxis de la API oficial de X v2 para excluirlos. No son inversos exactos: filter:retweets históricamente incluye tanto los retweets de estilo viejo "RT" como los tweets citados, mientras que el is:retweet de la API v2 es más estrecho. Para excluir cada forma de amplificación del lado web, usa -filter:retweets -filter:quote juntos.

¿Cuántos operadores de búsqueda puedo combinar en una consulta?

X empieza a ignorar operadores en silencio después de aproximadamente 22 a 23 en una sola consulta, así que la parte final de una consulta demasiado larga se descarta sin un error. La API oficial de X v2 también limita la cadena de consulta en sí a 512 caracteres para la búsqueda reciente autoservicio, 1,024 para el archivo completo, y 4,096 solo en el nivel enterprise.

¿Hay una API de Twitter/X que admita el conjunto completo de operadores de búsqueda?

Sí. La API oficial de X v2 admite solo un subconjunto de operadores de búsqueda, pero el endpoint Search Tweets de Sorsa pasa el conjunto completo de operadores web, incluidos min_faves:, since:/until:, y filter:blue_verified. Corre a 20 solicitudes por segundo en todos los planes sin ventanas por endpoint y sin aprobación de cuenta de desarrollador, y devuelve el perfil del autor de cada tweet sin costo extra.


Revisado por Keksich, fundador de Sorsa, especialista en marketing e investigador de la API de X.

Fuentes y cómo revisamos esto

Esta guía se apoya en nuestro trabajo práctico construyendo y operando una API alternativa de Twitter/X (más de 5 mil millones de solicitudes procesadas desde 2022), probada contra nuestro endpoint Search Tweets en vivo, más la referencia twitter-advanced-search mantenida por la comunidad de Igor Brigadir y la documentación de operadores de la API oficial de X v2. Cada operador listado aquí se volvió a revisar contra el comportamiento de búsqueda vigente de X en junio de 2026, y las diferencias web-versus-API-v2 se verificaron contra la propia lista de operadores publicada de X el día de esta revisión. La referencia de operadores también vive en los docs de Sorsa si la quieres junto a la referencia de endpoints.


Cómo empezar

La forma más rápida de poner esta guía a trabajar:

  1. Abre el Search Builder y ensambla una consulta de forma visual. Sin inicio de sesión, y sin límite de tasa al construir.
  2. Córrela en el Playground de Sorsa para ver resultados en vivo con exportación a JSON y CSV.
  3. Cuando estés listo para programarla, pon tu consulta en el ejemplo de Python o JavaScript de arriba y llama al endpoint de búsqueda con tu clave API. Cada cuenta empieza con 100 solicitudes gratis: por única vez, sin tarjeta requerida, válidas en los 40 endpoints, y suficiente para hasta 10,000 tweets o 20,000 perfiles. El quickstart recorre la creación de la clave si aún no lo has hecho.

¿Vienes de la API oficial de X v2 y cansado de operadores que calladamente no hacen nada? La guía de migración mapea las diferencias endpoint por endpoint, y en los endpoints por lotes Sorsa sale desde $0.02 por cada 1,000 tweets y desde $0.01 por cada 1,000 perfiles, sobre un límite de tasa de 20 solicitudes por segundo sin cola de aprobación. El precio completo es público.