API de monitoramento do Twitter em tempo real

#Como funciona o monitoramento do Twitter em tempo real

O monitoramento do Twitter em tempo real é um loop. Ele pede ao X os posts mais novos de um feed, guarda os que ainda não tratou e pergunta de novo alguns segundos depois. Esse loop se chama polling. O feed pode ser uma conta, uma Lista de contas ou uma busca por palavras: o nome de uma marca, o handle de um concorrente, uma cashtag, uma palavra-chave de queda de serviço ou os analistas cujos posts movem um mercado.

Todo post no X tem um ID numérico que cresce com o tempo, então o maior ID que você já processou funciona como checkpoint: tudo acima dele é novo. O intervalo entre as consultas define a espera máxima. Um post publicado logo depois de uma consulta espera um intervalo inteiro até a próxima; um post publicado logo antes de uma consulta é pego na hora.

A API oficial do X funciona ao contrário, por push. O Filtered Stream mantém uma conexão HTTP aberta e envia todo post que corresponde às suas regras, e a documentação do Filtered Stream do X (abre em uma nova aba) estima o atraso em cerca de 4 a 5 segundos para 99% dos posts. O acesso por pagamento por uso permite 1 conexão, 1.000 regras de até 1.024 caracteres e 250 posts por segundo, e exige uma conta de desenvolvedor aprovada, um projeto, um app e um Bearer token.

O X cobra cada post que o stream entrega como uma leitura de post: US$ 0,005, ou US$ 5,00 por 1.000, até 3 milhões de leituras de posts por mês, antes de um contrato Enterprise. A partir de 22 de novembro de 2026, o perfil de um autor devolvido com um post custa US$ 0,010 a mais, segundo o aviso do X de 23 de outubro (abre em uma nova aba), de modo que um post com seu autor sai por US$ 0,015. Todas as outras tarifas oficiais estão detalhadas no guia de preços da API do X.

#Monitore contas e palavras-chave com a Sorsa API

Para monitorar o X por código, use a Sorsa API, uma API e scraper do Twitter (X): uma requisição lê os posts mais novos de até 5.000 contas, os feeds de palavras-chave aceitam a própria sintaxe de busca do X, e todos os planos rodam 20 requisições por segundo. Cada consulta devolve dados novos, cada post com o perfil completo do autor, atrás de um único cabeçalho ApiKey em vez de uma conta de desenvolvedor e OAuth.

Escolha o endpoint conforme o que você acompanha. Cada um devolve uma página de cerca de 20 posts, dos mais novos para os mais antigos, e um next_cursor para a página anterior.

• Até 5.000 contas

  Endpoint

  GET /list-tweets (abre em uma nova aba)

  O que uma requisição devolve

  Os posts mais novos de todos os membros de uma Lista pública

• Uma conta

  Endpoint

  POST /user-tweets (abre em uma nova aba)

  O que uma requisição devolve

  Seus posts, respostas ou reposts mais novos

• Palavras, hashtags, cashtags

  Endpoint

  POST /search-tweets (abre em uma nova aba)

  O que uma requisição devolve

  Os resultados mais novos com "order": "latest"

• Posts que marcam um handle

  Endpoint

  POST /mentions (abre em uma nova aba)

  O que uma requisição devolve

  As menções mais novas, com filtros de curtidas e de data

1. Obtenha uma chave. Cadastre-se e copie a chave de API do seu painel. As 100 requisições grátis já estão nela.

2. Coloque as contas em uma Lista pública do X. Crie uma Lista no x.com, adicione até 5.000 contas e deixe-a pública: nenhuma chave de API consegue ler uma Lista privada. O ID da Lista é o número no fim do endereço dela no x.com, e é o list_id que a requisição abaixo envia.

3. Consulte a Lista. Uma única requisição GET devolve de uma vez os posts mais novos de todos os membros, cada um com o perfil do autor.

   curl -G "https://api.sorsa.io/v3/list-tweets" \
     -H "ApiKey: YOUR_API_KEY" \
     --data-urlencode "list_id=1849722563900214388"
   

   {
     "tweets": [
       {
         "id": "2117190277605314310",
         "full_text": "Status update: EU-West checkout errors are resolved.",
         "created_at": "2026-11-02T09:41:12Z",
         "lang": "en",
         "likes_count": 14,
         "retweet_count": 5,
         "reply_count": 3,
         "quote_count": 1,
         "view_count": 2140,
         "is_reply": false,
         "conversation_id_str": "2117190277605314310",
         "user": {
           "id": "1702291101836602498",
           "username": "harborline_status_hq",
           "display_name": "Harborline Status",
           "followers_count": 48210,
           "verified": false
         }
       },
       {
         "id": "2117190206607470143",
         "full_text": "Our Q3 freight index is out: spot rates down 4%.",
         "created_at": "2026-11-02T09:40:55Z",
         "lang": "en",
         "likes_count": 31,
         "retweet_count": 9,
         "reply_count": 4,
         "quote_count": 2,
         "view_count": 5320,
         "is_reply": false,
         "conversation_id_str": "2117190206607470143",
         "user": {
           "id": "1366689741639744314",
           "username": "quaywright_analytics",
           "display_name": "Quaywright Analytics",
           "followers_count": 12904,
           "verified": true
         }
       }
     ],
     "next_cursor": "DAABCgABG3kQ8x7_7ToKAAIbeRDz9yz3QAgAAwAAAAIAAA"
   }
   

   Ver resposta completa

4. Guarde só os posts novos. Compare cada ID com o seu checkpoint, siga o next_cursor quando mais de uma página tiver chegado desde a última consulta e ignore os IDs que você já tratou. O loop abaixo faz as três coisas a cada 5 segundos e reconfere os IDs dos últimos 2 minutos, para que um post que chega atrasado ao feed ainda seja pego.

   import time
   import requests
   
   API = "https://api.sorsa.io/v3"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   LIST_ID = "1849722563900214388"
   INTERVAL = 5              # seconds between polls
   OVERLAP = 120_000 << 22   # re-check the last 2 minutes of IDs
   
   
   def read_newer(floor):
       """Read pages until posts at or below floor show up."""
       posts, params = [], {"list_id": LIST_ID}
       for _ in range(5):  # at most 5 pages per poll
           r = requests.get(f"{API}/list-tweets", headers=HEADERS,
                            params=params, timeout=30)
           r.raise_for_status()
           page = r.json()
           tweets = page.get("tweets", [])
           newer = [t for t in tweets if int(t["id"]) > floor]
           posts += newer
           cursor = page.get("next_cursor")
           if not floor or len(newer) < len(tweets) or not cursor:
               break
           params["next_cursor"] = cursor
       return sorted(posts, key=lambda t: int(t["id"]))
   
   
   def handle(t):
       print(t["user"]["username"], t["created_at"], t["full_text"][:80])
   
   
   last_id, seen, first = 0, set(), True
   while True:
       try:
           posts = read_newer(max(last_id - OVERLAP, 0))
       except requests.RequestException as err:
           print("poll failed, retrying:", err)
           time.sleep(INTERVAL * 2)
           continue
       for t in posts:
           if t["id"] not in seen:
               seen.add(t["id"])
               if not first:  # the first poll only sets the checkpoint
                   handle(t)
           last_id = max(last_id, int(t["id"]))
       first = False
       time.sleep(INTERVAL)
   

   const API = "https://api.sorsa.io/v3";
   const headers = { ApiKey: "YOUR_API_KEY" };
   const LIST_ID = "1849722563900214388";
   const INTERVAL = 5_000;           // 5 seconds between polls
   const OVERLAP = 120_000n << 22n;  // re-check the last 2 minutes of IDs
   
   const sleep = (t) => new Promise((r) => setTimeout(r, t));
   
   async function readNewer(floor) {
     const posts = [];
     const params = new URLSearchParams({ list_id: LIST_ID });
     for (let i = 0; i < 5; i++) {
       const res = await fetch(`${API}/list-tweets?${params}`, { headers });
       if (!res.ok) throw new Error(`HTTP ${res.status}`);
       const page = await res.json();
       const tweets = page.tweets ?? [];
       const newer = tweets.filter((t) => BigInt(t.id) > floor);
       posts.push(...newer);
       if (!floor || newer.length < tweets.length || !page.next_cursor) break;
       params.set("next_cursor", page.next_cursor);
     }
     return posts.sort((a, b) => (BigInt(a.id) < BigInt(b.id) ? -1 : 1));
   }
   
   let lastId = 0n;
   let first = true;
   const seen = new Set();
   while (true) {
     try {
       const floor = lastId > OVERLAP ? lastId - OVERLAP : 0n;
       for (const t of await readNewer(floor)) {
         if (!seen.has(t.id)) {
           seen.add(t.id);
           if (!first) console.log(t.user.username, t.full_text.slice(0, 80));
         }
         if (BigInt(t.id) > lastId) lastId = BigInt(t.id);
       }
       first = false;
     } catch (err) {
       console.error("poll failed, retrying:", err.message);
       await sleep(INTERVAL);
     }
     await sleep(INTERVAL);
   }
   

5. Adicione feeds de palavras-chave. Para uma marca ou uma cashtag, consulte o POST /search-tweets com "order": "latest" e coloque o operador since_id: na consulta, para que cada rodada devolva só resultados mais novos. Os reposts nativos ficam fora dos resultados, a menos que a consulta acrescente include:nativeretweets, e o guia da API de busca do Twitter lista os outros operadores.

   floor = max(last_id - OVERLAP, 0)
   query = '("lumenforge" OR #lumenforge OR $LMFG) lang:en'
   body = {"query": f"{query} since_id:{floor}", "order": "latest"}
   r = requests.post(f"{API}/search-tweets", headers=HEADERS,
                     json=body, timeout=30)
   

6. Envie cada post novo para onde ele é necessário. A função handle() é sua para substituir: grave o post em um banco de dados, publique-o em um canal de equipe no Slack ou passe-o a um agente de IA que classifica e resume.

#Uma Lista do X cobre 5.000 contas

Uma Lista do X transforma milhares de contas em um único feed, e é isso que mantém o polling barato em escala. Acompanhar 5.000 contas uma a uma exige 5.000 requisições de timeline a cada consulta. Coloque-as em uma Lista pública e cada consulta passa a ser uma única requisição ao GET /list-tweets, não importa quantos membros postaram.

Assim, o rate limit deixa de ser o gargalo. A Sorsa API permite 20 requisições por segundo por chave em todos os planos, inclusive nas contas gratuitas. Uma chave consegue consultar 20 Listas por segundo, ou 600 Listas que cobrem até 3 milhões de contas a cada 30 segundos. Na API oficial do X, o endpoint de timeline de Lista permite 900 requisições a cada 15 minutos por app, cerca de uma por segundo, e cobra todo post que devolve. O guia sobre os rate limits da API do X traz a tabela completa.

Cada requisição devolve cerca de 20 posts. Quando uma Lista publica mais do que isso entre duas consultas, o loop acima segue o next_cursor de volta até o checkpoint, com uma requisição a mais por página extra. Um intervalo menor faz o mesmo trabalho. Ler os membros e os seguidores de uma Lista e criar Listas em massa é assunto do guia da API de Listas e Comunidades do X.

#Com que frequência consultar e quanto custa

Escolha o intervalo pela espera máxima que a sua tarefa aceita e depois conte as consultas. A Sorsa API cobra uma requisição por consulta, quer a página tenha 20 posts novos ou nenhum, então o custo mensal depende de dois números: quantos feeds você consulta e com que frequência. Em um mês de 30 dias, um feed consultado a cada 30 segundos faz cerca de 86 mil requisições, o que cabe nas 100 mil do plano Pro. Por feed, cada intervalo sai assim:

• 5 segundos

  Requisições por mês

  518 mil

  A partir de

  US$ 726

  Na tarifa do Pro

  US$ 1.032

• 15 segundos

  Requisições por mês

  173 mil

  A partir de

  US$ 242

  Na tarifa do Pro

  US$ 344

• 30 segundos

  Requisições por mês

  86 mil

  A partir de

  US$ 121

  Na tarifa do Pro

  US$ 172

• 1 minuto

  Requisições por mês

  43 mil

  A partir de

  US$ 60

  Na tarifa do Pro

  US$ 86

• 5 minutos

  Requisições por mês

  8,6 mil

  A partir de

  US$ 12

  Na tarifa do Pro

  US$ 17

A coluna "A partir de" usa a menor tarifa da Sorsa API, US$ 1,40 por 1.000 requisições; a tarifa do Pro é US$ 1,99. Um feed aqui é uma Lista de até 5.000 contas ou uma consulta de busca, então 5.000 contas consultadas a cada 30 segundos custam o mesmo que uma. O planejador abaixo soma feeds e mostra qual plano os cobre.

Por post, é em um feed movimentado que a diferença aparece. Uma Lista ou uma busca que enche a página de 20 posts a cada consulta coleta posts a partir de US$ 0,07 por 1.000 na Sorsa API. A API oficial do X cobra US$ 5,00 por 1.000 posts que o stream entrega, e US$ 15,00 por 1.000 quando passar a cobrar, a partir de 22 de novembro, o autor devolvido com cada post.

Requisições com falha nunca são cobradas, e o GET /key-usage-info (abre em uma nova aba) informa as requisições que restam em uma chave sem gastar nenhuma.

#Social listening no X com uma API

Fazer social listening no X é coletar o que as pessoas postam sobre uma marca, um produto ou um assunto e transformar isso em números: volume, sentimento, alcance e as contas que impulsionam a conversa. Uma ferramenta de listening faz isso dentro do próprio painel. Com uma API, você coleta os posts e calcula os números no seu código, no seu data warehouse ou no seu agente de IA.

Em comparação com o conector de X de uma ferramenta de listening multirrede, uma API de dados dedicada ao X oferece:

• as respostas, os quotes e os retweeters completos de qualquer post público, página por página;
• a sintaxe de busca do próprio X, de frases exatas a lang:, min_faves: e from:;
• buscas em qualquer janela de datas desde 2006, para comparar um lançamento com os anteriores;
• o perfil completo do autor dentro de cada post, sem chamada extra;
• JSON bruto, sem licenças por usuário e sem limites de exportação, a um preço fixo por requisição.

As menções à marca vêm de dois feeds: o POST /mentions pega os posts que marcam o seu handle, e uma busca pelo nome pega os que nunca o marcam. O guia da API de menções do Twitter une os dois pelo ID do tweet. Em torno de qualquer post que decola, POST /comments (abre em uma nova aba), POST /quotes (abre em uma nova aba) e POST /retweeters (abre em uma nova aba) leem as respostas, os quote posts e as contas que deram repost. O GET /followers (abre em uma nova aba) lê um público de 200 perfis por página, o GET /info-batch (abre em uma nova aba) lê 100 perfis de uma vez, e o GET /trends (abre em uma nova aba) devolve o que está em alta em um país ou uma cidade pelo WOEID.

As métricas que uma equipe calcula a partir do feed

• Share of voice: execute a mesma consulta para a sua marca e para cada concorrente na mesma janela e compare os posts encontrados, com as visualizações e o alcance em seguidores por trás deles. O guia de análise de concorrentes no Twitter monta a comparação completa.
• Sentimento: classifique o texto de cada post como positivo, negativo ou neutro com um modelo seu ou um LLM, como em nosso guia de análise de sentimento no Twitter.
• Alcance e amplificação: some view_count, retweet_count e quote_count dos posts de uma janela.
• Principais vozes: ordene os autores por followers_count e pelo engajamento que seus posts geraram.

Para fazer social listening no X por código, a Sorsa API devolve resultados de busca a partir de US$ 0,07 por 1.000, com histórico desde 2006, e a mesma chave roda o monitor ao vivo acima.

#Mantenha o monitor confiável

Um monitor que roda por meses enfrenta reinícios, picos e posts que chegam fora de ordem. Cinco hábitos evitam que ele perca posts ou relate um duas vezes:

• Guarde o checkpoint. Mantenha o último ID em uma linha de banco de dados ou em um arquivo, para que uma reinicialização retome de onde parou, em vez de reprocessar posts antigos ou pular posts novos.
• Reconfira uma sobreposição curta. Um post pode chegar a um feed de Lista ou de busca alguns segundos depois de um mais novo. Reler 2 minutos de IDs a cada consulta e ignorar os IDs já tratados pega essas chegadas atrasadas.
• Compare IDs, não posições. O POST /user-tweets pode devolver primeiro o post fixado de uma conta, então tome o maior ID da página como o mais novo.
• Recue quando houver erros. Um 429 significa que a chave passou de 20 requisições por segundo: espere e tente de novo. Um 403 significa que a chave ficou sem requisições. Nenhum dos dois custa nada, porque requisições com falha não são cobradas.
• Atualize as contagens depois. Um post pego segundos depois de publicado quase não tem curtidas nem visualizações ainda. Releia os posts que você guardou uma hora depois com o POST /tweet-info-bulk (abre em uma nova aba), 100 por requisição, o que leva os tweets já conhecidos a partir de US$ 0,014 por 1.000.

Bom saber

O polling lê apenas dados públicos. Contas protegidas, Listas privadas e mensagens diretas nunca aparecem em nenhum feed. A Sorsa API é somente leitura por princípio: ela nunca posta, curte ou segue, e nunca pede seu login do X, então sua própria conta do X não corre nenhum risco.

#Comece seu primeiro monitor em tempo real

O monitoramento do Twitter em tempo real se resume a um intervalo e um checkpoint: um loop de 5 segundos sobre uma Lista pública vigia 5.000 contas com uma requisição por consulta. A Sorsa API roda esse loop com uma chave de API a 20 requisições por segundo em todos os planos, com os posts coletados a partir de US$ 0,07 por 1.000, contra US$ 5,00 na API oficial do X. Coloque suas contas em uma Lista, execute o loop acima com as suas 100 requisições grátis e acrescente feeds de palavras-chave quando os primeiros posts chegarem.

#Perguntas frequentes