A lista de operadores de busca avançada do X: o que a busca web aceita e o que a API rejeita

Como é a lista completa de operadores de busca avançada do X?

Dois conjuntos documentados formam a lista de operadores de busca avançada do X: os campos que a central de ajuda do X expõe pelo formulário de busca avançada no x.com, e os operadores que a documentação para desenvolvedores do X define para os endpoints de busca v2. Os conjuntos coincidem em palavras-chave, contas e idioma, e depois se separam em datas, limiares de engajamento e geografia, porque a busca web manteve a sintaxe da API standard v1.1 aposentada enquanto a v2 ganhou nomes de operador novos. Confira de que lado dessa divisão você está antes de escrever um único caractere.

Função	Operador	O que encontra	Busca web	X API v2
Conteúdo	keyword	Uma palavra tokenizada no corpo do post	Sim	Sim
Conteúdo	"exact phrase"	As palavras nessa ordem	Sim	Sim
Conteúdo	#hashtag	A hashtag, correspondência exata	Sim	Sim
Conteúdo	$cashtag	Um símbolo de ação	Não verificado	Sim
Conteúdo	url:	Um token dentro do link ou do link expandido	Não verificado	Sim
Conteúdo	lang:en	O idioma que o X atribuiu ao post	Sim	Sim, exige conjunção
Conteúdo	-term, OR, ( )	Excluir, alternar, agrupar	Sim	Sim
Contas	from:handle	Posts escritos por essa conta	Sim	Sim
Contas	to:handle	Respostas dirigidas a essa conta	Sim	Sim
Contas	@handle	Posts que mencionam essa conta	Sim	Sim
Contas	list:id	Posts dos membros de uma Lista	Não verificado	Sim
Contas	retweets_of:handle	Reposts dessa conta	Não	Sim
Contas	is:verified	Posts de um autor verificado	Não verificado	Sim, exige conjunção
Contas	bio:, bio_name:	Texto no perfil do autor	Não	Somente Enterprise Powerstream
Engajamento	min_faves:25	Pelo menos 25 likes	Sim	Rejeitado com 400
Engajamento	min_retweets:10	Pelo menos 10 reposts	Sim	Rejeitado com 400
Engajamento	min_likes:25	Pelo menos 25 likes	Não	Sim
Engajamento	min_reposts:10	Pelo menos 10 reposts	Não	Sim
Engajamento	min_replies:3	Pelo menos 3 respostas	Não verificado	Sim
Datas	since:2026-08-01	Posts daquele dia em diante	Sim	Não, use start_time
Datas	until:2026-09-01	Posts anteriores àquele dia	Sim	Não, use end_time
Datas	start_time, end_time	Limites em ISO 8601	Não	Sim, parâmetros de requisição
Datas	since_id, until_id	Limites por ID de post	Não	Sim, parâmetros de requisição
Mídia	has:media, has:images, has:videos, has:links	Um anexo ou um link	Não verificado	Sim, exige conjunção
Mídia	has:hashtags, has:cashtags, has:mentions, has:geo	Essa entidade presente em qualquer lugar	Não verificado	Sim, exige conjunção
Mídia	is:retweet, is:reply, is:quote	Tipo de post	Não verificado	Sim, exige conjunção
Mídia	-is:nullcast	Descarta os posts só promovidos	Não	Sim, negação obrigatória
Geo	near:"San Francisco, CA"	Posts marcados perto de um lugar	Sim	Não
Geo	within:15mi	Raio, anda junto com near:	Sim	Não
Geo	place:seattle	Um lugar marcado	Não	Sim
Geo	place_country:US	Um código de país ISO	Não	Sim
Geo	point_radius:[2.355128 48.861118 16km]	Um círculo em volta de uma coordenada	Não	Sim
Geo	bounding_box:[-105.30 39.96 -105.17 40.09]	Um retângulo de coordenadas	Não	Sim
Threads	conversation_id:1334987486343299072	Todos os posts de uma thread	Não	Sim
Threads	in_reply_to_tweet_id:, quotes_of_tweet_id:, retweets_of_tweet_id:	Respostas, citações e reposts de um post	Não	Sim
Threads	context:, entity:	As anotações de tema do próprio X	Não	Sim, entity: só em recent search

Última verificação: 8 de setembro de 2026

Fontes: X Help Center, How to use advanced search, rodapé carimbado 2026 X Corp, lido em 8 de setembro de 2026. Documentação para desenvolvedores do X, Search Operators e Build a query, lidos em 8 de setembro de 2026.

Quais operadores funcionam na busca web gratuita sem chave de API?

Quatorze operadores levam um Sim na coluna web acima porque a central de ajuda do X os confirma, e todas as outras entradas web são inferência. Essa página documenta os campos do formulário de busca avançada e depois linka duas buscas prontas cujas URLs soletram a sintaxe: New Years -Resolution lang:en near:"San Francisco, CA" within:15mi since:2013-12-30 until:2014-01-02 e #WorldCup lang:en near:"Brazil" within:15mi until:2014-07-31. Trate essas duas URLs como a referência web e teste você mesmo qualquer coisa que passe disso.

O X impõe uma condição de acesso. A central de ajuda dele diz que a busca avançada "is available when you're logged in to X.com," (está disponível quando você está logado no X.com), então a busca web é gratuita, mas não dispensa uma conta.

Quais operadores do X só funcionam pela API?

Threads, anotações e geografia precisa são exclusivos da API, porque esses operadores apontam para IDs de post e geometria de coordenadas para as quais o formulário web não tem campo. conversation_id: puxa todas as respostas de uma thread, context: casa com as anotações de tema do próprio X, e point_radius: recebe uma longitude, uma latitude e um raio. Recorra à API quando sua pergunta for sobre o formato de uma conversa e não sobre as palavras dentro dela.

O tamanho da consulta é o teto real da API. A documentação do X limita uma consulta de recent search self-serve a 512 caracteres, a de full-archive a 1.024 e a de enterprise a 4.096, e a string inteira conta. A conta para uma lista de palavras-chave cabe em uma linha:

Characters = (variants x average variant length) + (OR joins x 4) + (parentheses x 2)

Vinte variantes de um nome de produto com média de 12 caracteres, unidas por OR dentro de um grupo:

(20 x 12) + (19 x 4) + 2 = 240 + 76 + 2 = 318 characters

Isso deixa 512 menos 318 = 194 caracteres para lang:, -is:retweet e o resto no nível self-serve de recent search. O full-archive dobra o espaço para 1.024. Reserve primeiro o orçamento dos filtros e gaste o que sobrar em variantes, e leia quanto a API do X custa por nível e como funcionam as cotas de requisição dela antes de se comprometer com esse caminho.

Para onde vão os 512 caracteres de uma busca recent search

Variantes (20 x 12 caracteres)240

Junções OR (19 x 4)76

Parênteses2

Sobra para filtros194

Como definir limiares de engajamento na busca do X?

O X usa nomes diferentes para o mesmo limiar em cada superfície, e a própria referência de operadores dele diz isso em uma caixa de aviso: "The equivalent operators on X web search are named min_faves: and min_retweets:. Those names are not valid in the X API and will be rejected with a 400 error. Use min_likes: and min_reposts: instead." (Os operadores equivalentes na busca web do X se chamam min_faves: e min_retweets:. Esses nomes não são válidos na API do X e serão rejeitados com um erro 400. Use min_likes: e min_reposts: no lugar.) min_replies: mantém o nome dos dois lados. Cada um aceita um inteiro não negativo e funciona igual em recent search e em full-archive.

Os limiares cortam ruído e cortam intenção de compra ao mesmo tempo. Quem pede uma recomendação de ferramenta junta dois likes, não duzentos, então min_faves:50 apaga exatamente os posts que valem uma resposta. Suba os limiares para acompanhar concorrentes e crises, e zere ou omita os limiares quando estiver caçando intenção.

Como buscar um intervalo de datas exato no X?

A busca web aceita since: e until: com datas YYYY-MM-DD, e a API não aceita nenhum dos dois. since:2026-08-01 until:2026-09-01 devolve agosto na busca web; o mesmo intervalo na API são os parâmetros de requisição start_time e end_time em ISO 8601, com since_id e until_id como equivalentes por ID de post. A central de ajuda do X confirma que o arquivo web volta até o primeiro post público de 2006, e a API divide isso em recent search com 7 dias para qualquer desenvolvedor e full-archive até 2006 para os níveis pagos.

Os intervalos são semiabertos na busca web, então until:2026-09-01 para antes de 1 de setembro em vez de incluir esse dia. Some um dia à sua data final quando um relatório precisar contar o último dia.

Quais operadores de mídia e de geo ainda funcionam?

Todo operador has: e is: está documentado para a API e nenhum deles para a busca web, então a coluna de mídia é onde a maioria dos guias erra. A tabela de migração do X mapeia os nomes antigos da standard v1.1 para os novos: filter:links virou has:links, filter:media virou has:media, filter:images e filter:twimg viraram has:images, e filter:retweets virou is:retweet. A busca web descende dessa família herdada, e é por isso que a sintaxe filter: ainda circula e por isso que nada dela aparece na documentação atual do X.

A documentação do X também se contradiz sobre vídeo. A referência Search Operators lista has:video_link para vídeos nativos do X, enquanto a introdução de Search Posts e a tabela de migração listam as duas has:videos. Teste has:videos primeiro e deixe a alternativa à mão, porque uma das duas páginas está desatualizada e o X não diz qual.

A geografia se separa direitinho. near: mais within: pertencem à busca web, place:, place_country:, point_radius: e bounding_box: pertencem à API, e nenhum dos pares funciona do outro lado.

Três consultas que um profissional de marketing roda no X

Intenção de compra, busca web, só operadores verificados:

("looking for" OR "recommend a" OR "alternative to" OR "switching from") (CRM OR "help desk" OR helpdesk) lang:en since:2026-08-25 -from:YourBrand

Sinais de troca para a concorrência, busca web, com limiares ligados para só aparecer post com tração:

(@Competitor OR Competitor) (cancelled OR canceling OR "switching to") lang:en min_faves:5 since:2026-06-01 until:2026-09-01

A mesma caça por intenção pela API, onde todos os nomes de operador mudam:

("looking for" OR "any recommendations" OR "alternative to") ("project management" OR "task tracker") lang:en -is:retweet -is:nullcast -has:links min_likes:2

A ordem das operações decide o que cada uma devolve. O X combina AND antes de OR, então apple OR iphone ipad é avaliado como apple OR (iphone ipad), e os parênteses das três consultas acima sustentam a estrutura em vez de enfeitá-la. A lógica booleana genérica além disso pertence às regras por trás de AND, OR e NOT; esta página fica na sintaxe específica do X.

Quais operadores não puderam ser verificados?

Dez famílias de operadores aparecem na documentação do X apenas como nomes aposentados da standard v1.1, o que as deixa não verificadas em vez de funcionais: a família filter: inteira, source:, card_name:, card_domain:, include:antisocial, include:sensitive_content, filter:follows, filter:has_engagement, filter:trusted e o parâmetro de requisição geocode. A visão geral de migração do X lista cada uma sob uma coluna Standard com a coluna v2 em branco, e o endpoint standard v1.1 não existe mais.

A busca web nunca migrou para os nomes da v2, então herdou essa família antiga inteira, e o X não publica nenhuma lista do que sobreviveu. Rode cada operador contra uma consulta que você já sabe que devolve resultados e compare as contagens. O que devolver o conjunto sem filtro está sendo ignorado em vez de aplicado.

O RedReplier vigia o X junto com Reddit, Bluesky, Facebook e Hacker News em um lugar só, ordena o que encontra por intenção de compra e explica com IA por que cada menção foi marcada. O monitoramento de X dele recebe palavras-chave e um site em vez de uma string de consulta, e expõe uma API e um servidor MCP para Claude Code, Cursor e qualquer cliente MCP padrão. A prática em que isso tudo se encaixa é o social listening, e a versão construir ou comprar da pergunta é rodar você mesmo uma API de social listening.

Perguntas frequentes

A busca avançada do X funciona sem fazer login?

Não. A central de ajuda do X diz que a busca avançada está disponível quando você está logado no X.com. A busca não custa nada, mas precisa de uma conta, então um navegador deslogado ou um scraper sem autenticação não tira nenhum resultado da busca web.

Por que min_likes: falha na busca web?

A busca web e a API usam nomes diferentes para esse limiar. A referência de operadores do X diz que min_likes: e min_reposts: são os nomes da API e que min_faves: e min_retweets: são os nomes da busca web, e que os nomes web devolvem um erro 400 na API. Troque o par conforme a superfície que você está consultando.

Até onde a busca do X vai para trás?

Até o primeiro post público de 2006 na busca web, segundo a central de ajuda do X. A API divide esse arquivo: recent search cobre os últimos 7 dias para qualquer desenvolvedor, e full-archive search alcança 2006 para clientes de pagamento por uso e enterprise.

Posso usar near: e within: com a API do X?

Não. near: e within: são operadores exclusivos da busca web. Os equivalentes da API são place:, place_country:, point_radius:[longitude latitude radius] e bounding_box:.

É has:videos ou has:video_link?

O X documenta os dois. A página Search Operators dele lista has:video_link para vídeos nativos do X, enquanto a introdução de Search Posts e a tabela de migração de v1 para v2 listam has:videos. Teste os dois contra uma consulta que você sabe que devolve posts com vídeo e fique com o que mudar a contagem de resultados.

Por que minha consulta devolve menos posts do que eu espero?

Os operadores que exigem conjunção são a causa comum. A documentação do X diz que operadores como has:media, is:retweet e lang: não podem ficar sozinhos em uma consulta, então precisam de pelo menos um operador independente ao lado, como uma palavra-chave ou from:. A segunda causa é a precedência: AND liga mais forte que OR, então ponha parênteses em volta de cada grupo OR.

O limite de caracteres da API do X conta caracteres ou tokens?

A API do X conta caracteres, não tokens, e a string inteira da consulta entra no limite, operadores incluídos. A recent search self-serve tem teto de 512 caracteres, a full-archive dobra isso para 1.024, e a enterprise chega a 4.096. Reservar primeiro os operadores com conjunção obrigatória, como lang: e -is:retweet, deixa mais caracteres para as variantes de palavras-chave.

Por que -is:nullcast precisa de um sinal de menos na frente?

is:nullcast sozinho não é um operador válido da API do X, a documentação exige a negação -is:nullcast. Escrito assim, ele remove os posts só promovidos e mantém os orgânicos no resultado. Não existe uma forma positiva para pedir diretamente os posts nullcast.

Como verificar se um operador do X não verificado, como source: ou filter:trusted, ainda funciona?

Testa-se numa consulta que já se sabe que devolve resultados, uma vez com o operador e outra sem ele, comparando as contagens. Se o número não muda, o X está ignorando o operador em vez de aplicá-lo. Esse teste é necessário porque o X não publica uma lista de quais operadores aposentados do padrão v1.1 sobreviveram à mudança.

Por que guias antigos de busca do X listam operadores que hoje não devolvem nada?

Muitos guias copiam os nomes aposentados do padrão v1.1, como toda a família filter:, source: e card_name:, porque esses nomes funcionavam antes e quase nenhum site que os lista os marcou formalmente como obsoletos. A tabela de migração do X traduz só parte deles para nomes v2 como has:links ou is:retweet e deixa a coluna v2 em branco para o resto. Vale testar qualquer operador duvidoso antes de montar uma consulta em cima dele.