Operadores de busca do Twitter: folha de cola completa 2026 e API

Em resumo: Os operadores de busca do X são palavras-chave e símbolos que filtram tweets por autor, data, engajamento, mídia, idioma e localização. Eles transformam uma busca ampla por palavra-chave em uma consulta precisa, e mais de 50 funcionam na web em 2026. A API oficial do X v2 aceita apenas um subconjunto.

Por Sorsa Editorial

Atualizado em julho de 2026: reverificamos cada operador contra o comportamento de busca ao vivo do X e a API oficial do X v2, atualizamos o preço da Sorsa para as tarifas atuais por 1.000 em lote e adicionamos a franquia inicial de 100 requisições grátis. Revisões anteriores adicionaram a seção de operadores frequentemente confundidos, expandiram a referência de operadores quebrados e adicionaram orientação de paginação profunda.

A maioria das folhas de cola pula em silêncio a parte que mais importa para o trabalho real: os operadores de maior valor são operadores de busca da web que a API oficial do X v2 não aceita. min_faves:, min_retweets:, a rica sintaxe de data since:/until:, within_time: e filter:blue_verified todos funcionam na caixa de busca do x.com, e todos são descartados em silêncio pelo /2/tweets/search/recent. A Sorsa API, uma API alternativa do Twitter (X), repassa o conjunto completo de operadores da web direto pelo seu endpoint Search Tweets, então cada operador neste guia roda em código de produção, não só no site. Ela cobra por requisição em vez de por recurso, roda a um fixo de 20 requisições por segundo em todo plano sem janelas por endpoint, e não precisa de aprovação de conta de desenvolvedor, que é por que os pipelines movidos a operadores tendem a deixar a API oficial para trás.

Este guia é feito para dois leitores: o profissional de marketing que quer consultas de copiar e colar que simplesmente funcionam, e o desenvolvedor que precisa rodar essas consultas em escala. Cada operador abaixo é agrupado pelo que ele filtra, com um exemplo funcional, e o livro de receitas os transforma em 14 padrões de consulta prontos para rodar.

Para dar crédito a quem merece, esta referência se apoia em testes do mundo real mais a referência twitter-advanced-search mantida pela comunidade, de Igor Brigadir, a fonte de referência do setor sobre o comportamento não documentado de busca do X.

Índice

1. Como os operadores de busca do X funcionam
2. Operadores da web contra operadores da API oficial do X v2
3. Palavra-chave, frase e lógica booleana
4. Filtros de usuário e de conta
5. Restrição por engajamento
6. Filtros de mídia e de tipo de conteúdo
7. Data, hora e IDs Snowflake
8. Filtros geográficos
9. Filtros de idioma e de fonte
10. Operadores de card e de URL
11. Operadores que as pessoas confundem
12. Livro de receitas: 14 receitas prontas para produção
13. Usando operadores com a Sorsa API
14. Construindo consultas complexas: ordem das operações
15. O que está quebrado ou não confiável em 2026
16. Perguntas frequentes

Como os operadores de busca do X funcionam {#how-x-search-operators-work}

Os operadores de busca do X são pequenos comandos de texto que você acrescenta a uma consulta para filtrar o conjunto de resultados. Eles funcionam em três lugares: a barra de busca do x.com, o TweetDeck e qualquer API de terceiros que repasse a sintaxe completa de busca da web, como o endpoint Search Tweets da Sorsa. A sintaxe é operator:value sem espaço ao redor dos dois-pontos, e os operadores podem ser combinados livremente.

Os operadores caem em duas grandes categorias. Operadores autônomos podem ser usados por conta própria (por exemplo from:elonmusk retorna um conjunto de resultados válido). Operadores que exigem conjunção devem aparecer ao lado de pelo menos um operador autônomo, porque de outro modo corresponderiam a conteúdo demais. Essa distinção importa mais na API oficial do X v2 do que na web, mas vale entender desde o começo.

Três regras universais:

• AND é implícito. Colocar dois termos um ao lado do outro (bitcoin etf) exige ambos.
• OR deve ser maiúsculo. or minúsculo é tratado como uma palavra literal.
• A exclusão usa um traço inicial. crypto -scam remove resultados contendo "scam".

Se você planeja usar estes em produção, salve o Sorsa Search Builder nos favoritos. É uma ferramenta gratuita, sem login, que deixa você alternar filtros visualmente e gera uma query string pronta para copiar com cobertura completa de operadores. É a forma mais rápida de prototipar uma consulta antes de integrá-la ao código.

Operadores da web contra operadores da API oficial do X v2 {#web-operators-vs-official-x-api-v2-operators}

Esta é a coisa mais importante isolada que a maioria das folhas de cola não te diz. A sintaxe de busca avançada do X que funciona no x.com é um superconjunto da lista de operadores suportada pelo endpoint de busca da API oficial do X v2. Se você constrói um pipeline de produção no /2/tweets/search/recent e passa min_faves:100 since:2026-01-01 filter:blue_verified, nenhum desses três operadores faz nada. Eles não são erros. Eles são descartados em silêncio.

Vimos exatamente esse bug em vários projetos de migração desde 2024. A consulta "funciona", no sentido de que retorna tweets, mas a filtragem que você achava que tinha some. Quando alguém percebe, o painel esteve errado por semanas.

Aqui está a comparação operador por operador para os que os desenvolvedores de fato se importam:

As maiores baixas para o trabalho real são os filtros de engajamento (min_faves, min_retweets, min_replies) e a rica sintaxe de data. Sem min_faves:, você não consegue fazer emergir com eficiência conteúdo viral ou influente do lado da API v2. Você pode puxar tweets e filtrar no lado do cliente, mas em consultas de alto volume você acaba queimando a sua cota em tweets que descarta imediatamente, e a diferença de custo se compõe rápido.

Essa lacuna de custo é concreta. A API oficial do X v2 cobra por recurso: uma única busca retornando 20 posts mais os perfis dos autores deles custa cerca de US$ 0,30 (20 leituras de post a US$ 0,005 mais 20 leituras de usuário a US$ 0,010). A mesma chamada no plano Pro da Sorsa é uma requisição a cerca de US$ 0,002, com o perfil do autor de cada tweet incluído sem cobrança extra. A API oficial do X v2 também impõe limites rígidos de caracteres na própria query string, 512 caracteres para busca recente de autoatendimento, 1.024 para arquivo completo e 4.096 apenas no nível enterprise, enquanto a sintaxe web e o repasse da Sorsa são limitados apenas pelo teto prático de operadores de cerca de 22 a 23 operadores por consulta. Se você precisa postar ou enviar DMs, a API oficial ainda é a ferramenta para isso; para ler e buscar dados públicos com o conjunto completo de operadores, uma alternativa à API do Twitter (X) como a Sorsa é a razão pela qual as equipes de busca movidas a operadores trocam.

Divulgação: A Sorsa é o nosso produto. Mantivemos esta comparação estritamente factual; a lista de operadores ausentes é verificável contra a própria documentação pública de operadores do X no dia em que este artigo foi revisado. Para um olhar mais profundo nos tradeoffs, veja o nosso guia de migração da API oficial do X.

Palavra-chave, frase e lógica booleana {#keyword-phrase-and-boolean-logic}

Estes são os blocos fundamentais. Toda consulta avançada começa aqui.

Algumas notas práticas que pegam as pessoas. Plurais correspondem aos seus singulares e vice-versa: bulls vai corresponder a bull. O X às vezes reinterpreta em silêncio palavras comuns como intenção de conteúdo, então buscar photo pode retornar tweets com imagens anexadas mesmo quando a palavra "photo" está ausente do texto; envolva essas palavras em aspas duplas para forçar uma correspondência literal. Os operadores também não estão estritamente vinculados ao corpo do tweet: eles podem corresponder ao nome de exibição do autor, ao nome de tela e às URLs expandidas dentro do tweet, que é uma fonte frequente de resultados surpreendentes.

O teto no contador de operadores é real. Assim que você passa de cerca de 22 a 23 operadores em uma única consulta, o X começa a ignorar partes finais da string em silêncio. Se você precisa de mais do que isso, divida em várias chamadas de API e mescle os resultados downstream.

Filtros de usuário e de conta {#user-and-account-filters}

Estes filtram tweets por quem postou, a quem eles respondem ou quem é mencionado.

Truque de monitoramento de marca. Combine @ ou um nome de marca entre aspas com -from: para achar o que todos exceto a própria marca dizem sobre a marca: "Tesla" -from:tesla. Esse único movimento é a diferença entre sinal acionável e ruído de PR, e é a espinha dorsal da maioria das configurações de social listening.

Para um tratamento mais profundo de monitoramento de menções, veja a documentação sobre acompanhar menções; o operador list: combina naturalmente com a API de Listas do X quando você quer os tweets de cada membro em um feed.

Restrição por engajamento {#engagement-gating}

Filtre por engajamento mínimo (ou máximo). Estes são essenciais para cortar o ruído e fazer emergir conteúdo viral, e também são os operadores mais frequentemente ausentes na API oficial do X v2.

Como definir limiares. Comece baixo (min_faves:10) e aumente iterativamente. Os números do X ficam aproximados acima de cerca de 1.000, então não ajuste demais. Combine com -filter:retweets se você só quer tweets que ganharam engajamento no próprio conteúdo em vez de por amplificação. No nosso próprio trabalho de pipeline, a combinação min_faves:N mais -filter:retweets mais -filter:replies é o filtro mais útil isolado para fazer emergir conteúdo viral original; todo o resto é enfeite.

Filtros de mídia e de tipo de conteúdo {#media-and-content-type-filters}

O X tem um controle incomumente granular sobre que tipo de conteúdo aparece nos seus resultados. A pegadinha é que o conjunto de operadores da web é muito mais rico do que os equivalentes da API v2.

Filtros de mídia

Filtros de tipo de tweet

Filtros de conteúdo especial

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

A filtragem baseada em tempo precisa é crítica para análise de eventos, acompanhamento de campanha e extração de dados históricos. Este também é onde a API oficial do X v2 diverge mais fortemente: ela espera start_time e end_time como parâmetros de requisição separados e não entende since: / until: na query string. A sintaxe web e a Sorsa aceitam o conjunto completo.

O truque do ID Snowflake

Todo ID de tweet no X é um ID Snowflake que codifica seu timestamp de criação com precisão de milissegundo. A fórmula de conversão:

millisecond_epoch = (tweet_id >> 22) + 1288834974657

Isto é útil por dois motivos. Primeiro, você pode computar o horário exato de postagem de qualquer tweet sem fazer uma chamada de API, o que é prático para trabalhos de backfill que deduplicam ou ordenam por tempo. Segundo, since_id: e max_id: te dão limites em nível de tweet em vez de nível de data nas janelas de resultado, o que é inestimável quando você está paginando uma palavra-chave de alto volume por horas e quer retomar exatamente de onde parou sem re-buscar tweets que você já viu.

Para um passo a passo mais profundo de puxar conjuntos de tweets históricos, veja nosso guia sobre buscar tweets antigos.

Filtros geográficos {#geographical-filters}

Um teste de realidade antes de você ir fundo aqui: apenas cerca de 1 a 2 por cento dos tweets carregam dados de geolocalização precisos. O X removeu a marcação de localização precisa dos principais apps de iOS e Android em junho de 2019, e a maioria dos usuários nunca optou por isso de início. Os filtros de geo ainda são úteis, mas espere cobertura fina.

Do lado da API estruturada, a API oficial do X v2 usa um conjunto de geo diferente, place_country:, point_radius: e bounding_box:, no lugar dos operadores web near:/within:/geocode:. A Sorsa aceita os operadores geo da web pelo seu campo query, os mesmos que funcionam na caixa de busca do x.com; as formas da API v2 estão na tabela de comparação acima.

Um comportamento de fallback útil. Se um tweet não tem coordenadas precisas, a busca recorre a geocodificar reversamente a localização de perfil do usuário, então você pode receber tweets que casam com base na localização declarada do autor em vez da origem real do tweet. Isso às vezes é o que você quer e às vezes é confuso. Para uma abordagem de maior cobertura para mapear onde uma audiência está baseada, veja geografia de audiência por país.

Filtros de idioma e de fonte {#language-and-source-filters}

Idioma

O X usa códigos ISO 639-1 de 2 letras: lang:en, lang:es, lang:fr, lang:de, lang:ja, lang:ru, e assim por diante. Há também vários códigos não padrão que vale conhecer:

Um uso de alto sinal: from:user lang:zxx filter:images retorna tweets que são uma imagem e nada mais, com zero ruído de texto. A detecção de idioma do X não é perfeita, no entanto. Tweets curtos, trechos de código e posts cheios de emoji são rotineiramente mal classificados, então para aplicações críticas rode a sua própria detecção de idioma no texto do corpo após a recuperação.

Fonte (cliente de postagem)

Valores comuns: Twitter_for_iPhone, Twitter_for_Android, Twitter_Web_App, TweetDeck, twitter_ads. Note que source: às vezes precisa de outro operador ao lado para retornar resultados.

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

Estes correspondem a metadados de Twitter Card: as prévias ricas anexadas a tweets contendo links, mídia e conteúdo embutido. Duas coisas para saber logo de cara: card_name: tipicamente só funciona para tweets dos últimos 7 a 8 dias, e url: funciona bem para domínios mas não é confiável para caminhos de URL longos.

Operadores que as pessoas confundem {#operators-people-mix-up}

Um punhado de operadores parece intercambiável e não é. Estes são os pares que silenciosamente corrompem um dataset, então vale ser preciso sobre cada um.

filter:verified contra filter:blue_verified. filter:verified corresponde a contas que tinham verificação legada (jornalistas, figuras públicas, organizações verificadas antes de 2023). filter:blue_verified corresponde a qualquer um assinante do X Premium pago. A maioria das consultas de monitoramento de marca e editoriais quer filter:verified por sinal, não filter:blue_verified, que inclui qualquer usuário pagante. Para isolar contas legadas de forma limpa, combine-os: filter:verified -filter:blue_verified.

-filter:retweets contra include:nativeretweets contra -is:retweet. -filter:retweets (sintaxe web) exclui tanto retweets de texto estilo antigo "RT" quanto retweets nativos. include:nativeretweets adiciona retweets nativos de volta a um conjunto de resultados que os exclui por padrão. -is:retweet é a grafia da API oficial do X v2 para excluir retweets, e é mais estreita do que filter:retweets, que historicamente também varria quote tweets. Para um conjunto limpo de conteúdo original do lado web, use -filter:retweets; para rastrear o quão longe um tweet se espalhou, use filter:nativeretweets com uma janela de tempo apertada.

within_time:Xd contra since:/until:. within_time:7d é uma janela móvel medida a partir do momento em que a consulta roda, então a mesma consulta retorna um conjunto de tweets diferente amanhã do que hoje. since: e until: são limites de calendário fixos. Para datasets de pesquisa reprodutíveis, sempre prefira datas since:/until: explícitas a within_time:.

from:user contra @user. from:user retorna apenas tweets escritos por aquela conta. @user retorna qualquer tweet mencionando a conta, incluindo respostas e quote tweets de outras pessoas. Use from: para análise de linha do tempo e @ para monitoramento de menções; em @s de palavra comum, adicione lang:en ou um pequeno piso de engajamento às consultas @ para cortar ruído.

filter:retweets contra -is:retweet. filter:retweets é sintaxe web que corresponde a retweets; -is:retweet é a sintaxe da API v2 para excluí-los. Eles não são inversos perfeitos, então para excluir toda forma de amplificação do lado web, combine -filter:retweets com -filter:quote.

Estes operadores filtram tweets por tipo de interação. Recuperar as respostas, os quotes e quem deu retweet de fato por trás de um dado tweet é um trabalho separado, tratado por endpoints dedicados e coberto no guia da API de engajamento do Twitter.

Livro de receitas: 14 receitas prontas para produção {#cookbook-14-production-ready-recipes}

Os operadores são úteis isolados. Eles são poderosos em combinação. Aqui estão quatorze padrões de consulta que nós mesmos construímos ou vimos em pipelines de clientes. Copie-os, troque as variáveis e cole-os direto na barra de busca do X ou no endpoint de busca da Sorsa.

1. Monitoramento de marca e reputação

Ache conteúdo viral original sobre uma marca, excluindo os posts da própria marca e o ruído de retweet:

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

2. Geração de leads de concorrente

Ache usuários pedindo ativamente alternativas no seu nicho:

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

3. Descoberta de compradores de alta intenção

Ache tweets que se leem como sinais de compra para uma categoria de produto:

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

4. Descoberta de influenciadores

Posts originais de alto engajamento de contas verificadas em um tema:

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

5. OSINT e notícias de última hora

Rastreie eventos em tempo real com evidência visual de fontes verificadas:

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

6. Curadoria de conteúdo de Listas do X

Ache vídeos virais postados por membros de uma Lista específica:

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

7. Solução de problemas de desenvolvedor

Ache conversas relacionadas a erro linkando para o GitHub:

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

8. Sentimento de cripto com restrição por engajamento

Rastreie conversa carregada de sentimento sobre um token, filtrada por substância:

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

9. Monitoramento hiperlocal

O que está sendo dito perto de um lugar específico em uma janela de tempo apertada:

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

10. Ache quote tweets de um usuário específico

Faça correspondência de padrão na forma de URL e exclua o próprio @ do usuário:

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

11. Líderes de thread só originais

Ache tweets que iniciaram threads (não respostas, não retweets) e ganharam engajamento real:

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

12. Rastreie uma janela de lançamento de produto

Capture toda a conversa em um intervalo de data específico com um piso de engajamento:

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

13. Detecção de spam de engajamento zero

Identifique postagem suspeita de baixa qualidade (útil para pipelines de moderação):

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

14. Mineração de mural de vagas

Tweets de sinal de contratação em um nicho técnico específico:

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

O padrão em todas as quatorze: comece com o tema, sobreponha engajamento, sobreponha tipo de conteúdo, e depois sobreponha exclusões. As exclusões costumam ser o que separa um conjunto de resultados ruidoso de um aproveitável.

Usando operadores com a Sorsa API {#using-operators-with-the-sorsa-api}

Cada operador listado acima funciona no campo query do endpoint /v3/search-tweets da Sorsa. Passe a sua query string completa no corpo de uma requisição POST, pagine via next_cursor e trate os 429s com um retry breve. Para o fluxo mais amplo em torno de ordenação, paginação e tratamento de resultado, o guia de buscar tweets via API percorre isso de ponta a ponta.

Uma chamada mínima com curl:

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: pronto para produção com paginação e retry

Este é o padrão que rodamos em produção. Ele pagina o conjunto de resultados completo, tenta de novo em rate limiting e mostra erros duros:

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: padrão de iterador assíncrono

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);
}

A paginação profunda não é confiável: fragmente por data em vez disso

Uma coisa para planejar em qualquer extração histórica de alto volume: a paginação de busca do X é instável para conjuntos de resultados profundos. Este é um comportamento de plataforma upstream que todo caminho de acesso herda, não uma peculiaridade de uma API. Passada aproximadamente a primeira dúzia de páginas de uma única cadeia de cursor, você começa a ver duplicatas ou a cadeia para cedo, bem antes de o conjunto de resultados se esgotar.

A correção é parar de depender de uma longa cadeia de cursor e dividir a consulta em fragmentos por intervalo de data em vez disso. Rode várias consultas menores, cada uma delimitada por since: e until:, e pagine cada fragmento no seu próprio cursor fresco:

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 movimento rápido onde até uma semana é ampla demais, caia para fragmentos por hora usando a forma de timestamp completa (since:2026-03-01_12:00:00_UTC until:2026-03-01_13:00:00_UTC). Cada fragmento é reprodutível e retomável, o que importa quando você está reconstruindo a linha do tempo de um lançamento ou de um evento de notícias. Para pipelines de arquivamento que precisam capturar tweets específicos em vez de buscá-los, o endpoint tweet-info-bulk aceita até 100 IDs de tweet por requisição.

Construindo consultas complexas: ordem das operações {#building-complex-queries-order-of-operations}

Assim que você começa a empilhar cinco ou seis operadores, a ordem em que eles são avaliados começa a importar. A regra no X é a mesma que na maioria dos mecanismos de busca: AND liga mais forte do que OR.

Isso significa que cat OR black dog é avaliado como cat OR (black dog), não (cat OR black) dog. Se você quer a segunda interpretação, coloque parênteses: (cat OR black) dog. Na dúvida, use parênteses. Eles não te custam nada e eliminam a ambiguidade.

Uma ordem de montagem que funciona para quase toda consulta:

1. Agrupe as palavras-chave centrais entre parênteses: (bitcoin OR ethereum OR $BTC)
2. Adicione restrições de conteúdo: lang:en, filter:images, -filter:replies
3. Defina limiares de engajamento: min_faves:50, min_retweets:10
4. Exclua o ruído: -from:spambot, -scam, -airdrop, -filter:retweets
5. Adicione limites de tempo se necessário: since:2026-01-01 until:2026-03-01

Siga esta ordem de forma consistente e você conseguirá ler qualquer uma das suas consultas num relance e identificar erros mais rápido.

O que está quebrado ou não confiável em 2026 {#what-is-broken-or-unreliable-in-2026}

Os operadores falham em silêncio no X. A consulta ainda retorna tweets, então um filtro quebrado parece um funcionando até o dado já estar errado. Estes são os modos de falha que vale conhecer antes de eles morderem.

Operadores que não se comportam mais como seus nomes sugerem:

Situações comuns de "minha busca não está funcionando" e o que de fato está acontecendo:

• Você está em "Top" em vez de "Mais recentes". A aba Top padrão mostra uma seleção algorítmica e esconde a maioria das correspondências, o que se lê como resultados faltantes. Mude para a aba Mais recentes, ou passe order: "latest" na API, para cobertura completa.
• Uma busca de frase exata entre aspas retorna nada. As aspas forçam uma correspondência de token exata e desabilitam a correção ortográfica, então uma frase para a qual o X não tem correspondência exata volta vazia. Remova as aspas, ou use a forma de wildcard "word * word", para afrouxá-la.
• from: retorna nada ou lixo. A causa mais comum é um espaço depois dos dois-pontos: escreva from:username, nunca from: username, já que o espaço quebra o operador. A segunda causa mais comum é um intervalo de data durante o qual a conta não postou.
• geocode: ou near: retorna quase nada. A cobertura de geo colapsou após 2019; para trabalho de localização, apoie-se no fallback de localização de perfil ou analise onde uma audiência está baseada por país em vez de coordenadas em nível de tweet.
• A consulta funcionou no x.com mas não na API oficial do X v2. Quase sempre um operador só da web que a API descarta em silêncio; veja a tabela de comparação web contra API v2 acima.

Mais algumas pegadinhas duráveis:

• Teto de operadores: as consultas aceitam cerca de 22 a 23 operadores. Passe disso e a parte final da consulta é ignorada em silêncio.
• Contas privadas e suspensas são excluídas de todos os resultados de busca; nenhuma combinação de operador as alcança.
• Nem todos os tweets são indexados. Posts sinalizados por razões de plataforma ou de antispam são excluídos da busca mesmo quando tecnicamente ainda ativos. Esta é uma lacuna conhecida ao caçar contas com engajamento bloqueado (veja nosso texto sobre o erro "this request looks like it might be automated" do Twitter para contexto relacionado).
• A autocorreção acontece em silêncio em alguns casos; use +word ou "word" para forçar a correspondência exata.
• A correspondência de URL é frágil. Domínios e subdomínios funcionam, caminhos de URL longos não, e hífens em domínios devem ser substituídos por underscores (url:t_mobile.com).

Na prática

Uma equipe de análise social de cerca de 12 pessoas com quem trabalhamos tinha construído um painel de monitoramento de marca na API oficial do X v2. A consulta deles usava min_faves: e filter:blue_verified para fazer emergir apenas menções de alto sinal que valiam uma resposta humana. Na API v2, ambos são operadores só da web que são descartados em silêncio, então por semanas o painel de "top menções" estava ingerindo cada menção de baixo engajamento e a priorização era efetivamente aleatória. Ninguém viu um erro, porque não havia nenhum. Mover a mesma query string para uma API de busca que aceita o conjunto completo de operadores da web consertou isso sem reescrever nenhuma lógica de filtro, e como a cobrança é por requisição em vez de por recurso, o mesmo volume de monitoramento custou uma pequena fração do preço oficial por leitura de post. A falha era invisível precisamente porque os operadores que quebraram eram os que a API oficial nunca aceitou de início.

Perguntas frequentes {#faq}

O que é a busca avançada do X?

A busca avançada do X é a forma embutida da plataforma de filtrar tweets por autor, data, engajamento, tipo de mídia, idioma e localização. Ela está disponível como um formulário em x.com/search-advanced, ou você pode digitar os mesmos operadores diretamente na barra de busca de qualquer lugar. Uma vez que você conhece a sintaxe, digitar operadores é mais rápido do que preencher o formulário.

Como buscar no Twitter por data?

Para buscar no Twitter por data, combine since:YYYY-MM-DD e until:YYYY-MM-DD em uma consulta, por exemplo "product launch" since:2026-02-10 until:2026-02-17. A data since: é inclusiva e a data until: é exclusiva, então o tweet deve ser postado antes da data until, não nela. Para precisão sub-dia, use a forma de timestamp since:2026-02-10_14:00:00_UTC.

Por que meu operador de busca não está funcionando na API oficial do X?

Operadores como min_faves:, min_retweets:, since:, until:, within_time:, filter:blue_verified e card_name: são operadores de busca da web que a API oficial do X v2 não aceita; ela os ignora em silêncio em vez de retornar um erro. O endpoint de busca da Sorsa aceita o conjunto completo de operadores da web, que é por que as equipes que rodam pipelines filtrados por engajamento ou delimitados por data saem da API oficial.

Como achar tweets antigos sem uma conta do X?

O X exige login para a maioria das buscas em 2026, incluindo a barra de busca básica. Duas opções funcionam sem a sua própria conta: a Wayback Machine do Internet Archive para URLs de tweet específicas que você já tem, ou uma API do Twitter (X) de terceiros que mantém o próprio acesso ao índice de busca público, como a Sorsa, que retorna resultados históricos como JSON estruturado.

Qual é a diferença entre filter:retweets e -is:retweet?

filter:retweets é sintaxe de busca da web que corresponde a retweets, enquanto -is:retweet é a sintaxe da API oficial do X v2 para excluí-los. Eles não são inversos exatos: filter:retweets historicamente inclui tanto retweets de "RT" estilo antigo quanto quote tweets, enquanto o is:retweet da API v2 é mais estreito. Para excluir toda forma de amplificação do lado web, use -filter:retweets -filter:quote juntos.

Quantos operadores de busca posso combinar em uma consulta?

O X começa a ignorar operadores em silêncio depois de cerca de 22 a 23 em uma única consulta, então a parte final de uma consulta longa demais é descartada sem um erro. A API oficial do X v2 também limita a própria query string a 512 caracteres para busca recente de autoatendimento, 1.024 para arquivo completo e 4.096 apenas no nível enterprise.

Existe uma API do Twitter (X) que aceita o conjunto completo de operadores de busca?

Sim. A API oficial do X v2 aceita apenas um subconjunto de operadores de busca, mas o endpoint Search Tweets da Sorsa repassa o conjunto completo de operadores da web, incluindo min_faves:, since:/until: e filter:blue_verified. Ela roda a um fixo de 20 requisições por segundo em todo plano sem janelas por endpoint e sem aprovação de conta de desenvolvedor, e retorna o perfil do autor de cada tweet sem custo extra.

Revisado por Keksich, fundador da Sorsa, profissional de marketing e pesquisador da API do X.

Fontes e como checamos isto

Este guia se apoia no nosso trabalho prático construindo e operando uma API alternativa do Twitter (X) (mais de 5 bilhões de requisições servidas desde 2022), testado contra o nosso endpoint Search Tweets ao vivo, mais a referência twitter-advanced-search mantida pela comunidade, de Igor Brigadir, e a documentação oficial de operadores da API do X v2. Cada operador listado aqui foi rechecado contra o comportamento de busca atual do X em junho de 2026, e as diferenças entre web e API v2 foram verificadas contra a própria lista de operadores publicada do X no dia desta revisão. A referência de operadores também vive na documentação da Sorsa se você quiser tê-la ao lado da referência de endpoints.

Primeiros passos

A forma mais rápida de colocar esta folha de cola para trabalhar:

1. Abra o Search Builder e monte uma consulta visualmente. Sem login, e sem rate limit na montagem.
2. Rode-a no Playground da Sorsa para ver resultados ao vivo com exportação em JSON e CSV.
3. Quando estiver pronto para colocá-la em script, jogue a sua consulta no exemplo em Python ou JavaScript acima e chame o endpoint de busca com a sua chave de API. Toda conta começa com 100 requisições grátis: única vez, sem cartão, válidas em todos os 40 endpoints, e o bastante para até 10.000 tweets ou 20.000 perfis. O quickstart percorre a criação de chave se você ainda não fez isso.

Vindo da API oficial do X v2 e cansado de operadores que silenciosamente não fazem nada? O guia de migração mapeia as diferenças endpoint por endpoint, e nos endpoints de lote a Sorsa dá a partir de US$ 0,02 por 1.000 tweets e a partir de US$ 0,01 por 1.000 perfis, em um rate limit fixo de 20 requisições por segundo sem fila de aprovação. O preço completo é público.