Como fazer web scraping do Twitter (X) em 2026: métodos, ferramentas, código e custos

Por Sorsa Editorial

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

Atualizado em julho de 2026: verificamos o status das bibliotecas de código aberto no GitHub e no PyPI (twscrape, Scweet e Tweety funcionam; snscrape, Twint e ntscraper estão mortas; o Twikit oficial está quebrado no momento e roda em um fork da comunidade). O preço de pagamento por uso da API do X e seus Termos de Serviço de janeiro de 2026 foram reconferidos no mesmo mês.

Em resumo: Em 2026, dá para coletar dados públicos do Twitter (X) de três formas: dirigir um navegador headless e capturar as respostas GraphQL internas do X, rodar uma biblioteca de código aberto mantida em uma conta logada ou enviar uma URL para um scraper gerenciado. As três precisam de proxies residenciais, a maioria precisa de conta, e todas quebram a cada duas a quatro semanas quando o X rotaciona seus guest tokens e identificadores GraphQL. Uma API de dados somente leitura pula tudo isso e devolve os mesmos dados em JSON.

A maioria de quem pesquisa "como fazer scraping do Twitter" não quer, na verdade, um scraper. Quer os dados. São problemas diferentes: o dado é o objetivo, e um scraper é um compromisso permanente com proxies residenciais, contas descartáveis que acabam banidas e reengenharia reversa do X a cada duas semanas.

Nós construímos e operamos a Sorsa API, uma API de dados somente leitura do X (antigo Twitter), então trate esta seção como parte interessada. Ainda assim vale enunciar a troca com todas as letras: os mesmos perfis, tweets, resultados de busca e seguidores que um scraper luta para extrair voltam como JSON limpo de uma única chamada REST, sem proxies, sem login e sem manutenção. O preço parte de US$ 0,02 por 1.000 tweets e US$ 0,01 por 1.000 perfis nos endpoints em lote, um custo até 50x menor que o da API oficial do X, com limite fixo de 20 requisições por segundo em todos os planos. Não há inscrição nem fila de aprovação, a primeira chamada leva cerca de três minutos, e as primeiras 100 requisições são grátis, sem cartão.

Se você ainda quer construir o scraper, por controle, por aprendizado ou porque seu fluxo de trabalho realmente precisa, este guia é a versão honesta e atual: quais dados estão de fato ao alcance, código Python funcional, quais ferramentas estão vivas e quais estão mortas, quanto custa de verdade e onde ficam as linhas legais.

Índice

• Ainda é possível fazer scraping do Twitter em 2026?
• Quais dados você pode coletar (e o que está fora de alcance)
• É legal fazer scraping do Twitter?
• Como o X.com funciona por baixo do capô
• Método 1: scraping com navegador headless (com código)
• Método 2: bibliotecas Python de código aberto
• Método 3: scraping assistido por IA
• Método 4: serviços gerenciados de scraping
• Como achar URLs de tweets e perfis para coletar
• Quanto o scraping realmente custa
• Método 5: uma API de dados somente leitura (sem scraping)
• Qual método você deve usar?
• Perguntas frequentes
• Como verificamos este guia

Ainda é possível fazer scraping do Twitter em 2026? {#can-you-still-scrape-twitter-in-2026}

Sim. Dados públicos do Twitter continuam acessíveis por scraping em 2026 sem a API oficial, mas todos os caminhos fáceis se fecharam. Três mudanças explicam a dificuldade, e o resto deste guia trata basicamente de contorná-las.

Primeiro, o X trancou o acesso anônimo de convidado, e essa é a única mudança que matou o antigo conjunto de ferramentas gratuitas. Segundo, migrou a API oficial para pagamento por uso, sem plano gratuito de leitura, então "é só usar a API" passou a custar dinheiro desde a primeira requisição. Terceiro, apertou a detecção de bots em toda página pública, de modo que até um scraper funcional precisa de proxies residenciais e de um ritmo cuidadoso para sobreviver.

O retorno continua real. O X segue como uma das fontes mais ricas de opinião pública ao vivo que existem, e é por isso que as equipes continuam coletando dados dele para monitoramento de marca, análise de sentimento, pesquisa de concorrentes, geração de leads, detecção de tendências e datasets para machine learning. A dificuldade é justamente o motivo de um guia como este existir: o trabalho não está mais em fazer o parse do HTML, e sim em passar pelas defesas primeiro.

Quais dados você pode coletar (e o que está fora de alcance) {#what-data-can-you-scrape-and-what-is-off-limits}

Antes de escrever qualquer código, saiba onde fica o muro. Sem uma sessão logada, você alcança perfis públicos, tweets individuais e suas respostas visíveis, além dos metadados de mídia incorporada. Tudo o que fica atrás de autenticação, contas protegidas, mensagens diretas, listas completas de seguidores e resultados completos de busca, segue fora de alcance, a menos que você colete com uma conta real, o que traz risco de suspensão.

O acesso anônimo também tem limites mais suaves. A profundidade das respostas é rasa, e as visualizações de convidado, limitadas por rate limit, cortam timelines longas antes de você chegar ao fim. Históricos completos exigem automação intensa de rolagem, e mesmo assim você esbarra no teto da timeline de convidado. Se você precisa de histórico sem scraping, uma API de dados retorna tweets desde 2006 pela busca, além de listas completas de seguidores e de seguindo que nenhum scraper anônimo alcança.

O restante deste guia cobre apenas o que é público e não exige autenticação. Essa é a linha mais segura do ponto de vista legal e também a que não deixa sua conta banida.

É legal fazer scraping do Twitter? {#is-it-legal-to-scrape-twitter}

Coletar dados públicos do Twitter fica numa divisão real: os tribunais dos EUA em grande parte protegeram a prática, enquanto os próprios Termos de Serviço do X a proíbem categoricamente. As duas coisas são verdadeiras ao mesmo tempo, e qual delas pesa mais depende de o seu risco ser de direito penal ou contratual.

Na jurisprudência, a balança pende para os dados públicos. Em 2022, o Nono Circuito confirmou que coletar informação disponível publicamente não viola a Computer Fraud and Abuse Act, sendo a linha de casos hiQ v. LinkedIn a mais citada. O X testou isso diretamente e perdeu: uma corte federal arquivou o X Corp. v. Bright Data em maio de 2024, entendendo que as alegações do X contra o scraper eram em grande parte afastadas, e o processo do X contra o Center for Countering Digital Hate foi arquivado com base na Primeira Emenda. Acessar dados genuinamente públicos não é crime sob a CFAA.

No terreno contratual, os termos do X são a restrição mais dura. Os termos atuais, em vigor desde 15 de janeiro de 2026, vedam crawling ou scraping "em qualquer forma, para qualquer finalidade" sem consentimento prévio por escrito. Eles acrescentam uma cláusula de indenização predeterminada: quem solicitar, visualizar ou acessar mais de 1.000.000 de posts em qualquer período de 24 horas violando os termos concorda em pagar US$ 15.000 (ou o mesmo valor em euros na União Europeia, na EFTA e no Reino Unido) por milhão de posts. A atualização de 2026 também redefine "Conteúdo" para abranger prompts e saídas de IA, adiciona uma cláusula de uso indevido voltada a jailbreaking e prompt injection e fixa foro no Texas com renúncia a ação coletiva. Violar os termos é questão contratual, não crime, mas o X pode suspender contas, bloquear IPs e apontar para essa cláusula em escala.

Três regras mantêm o scraping público em terreno defensável: colete apenas dados públicos, nunca contas protegidas, DMs ou qualquer coisa atrás de um login; não acumule, guarde os dados coletados só pelo tempo que o seu caso de uso exigir; e respeite os rate limits, já que sobrecarregar servidores é onde o risco legal vira concreto. Quem está na União Europeia carrega mais uma camada, porque posts públicos ainda podem conter dados pessoais, então o GDPR se aplica sempre que você os armazena ou processa. Isto é informativo, não é aconselhamento jurídico; se o seu caso de uso envolve dados sensíveis ou alto volume, fale com um advogado.

Como o X.com funciona por baixo do capô {#how-xcom-works-under-the-hood}

Entender a arquitetura do X explica por que todo scraper acaba quebrando. Se você já fez scraping de outros sites, as defesas do X estão em outra liga, e os motivos são estruturais, não acidentais.

O X é uma single-page application em React. Carregue a URL de um perfil ou de um tweet e o servidor devolve uma casca de HTML quase vazia. O JavaScript então pede um guest token ao backend e dispara consultas GraphQL para buscar os dados reais, que o navegador renderiza. Quase não há nada útil no HTML inicial, então um scraping simples de baixar e fazer o parse não devolve nada. Esse desenho dá ao X três gargalos.

Guest tokens são credenciais temporárias exigidas em toda chamada GraphQL. Ficam presos ao seu IP, expiram em poucas horas, e a forma como são emitidos muda a cada poucas semanas. Quando o X altera a emissão de tokens, todo scraper que depende do método antigo deixa de funcionar na hora. Esse é exatamente o mecanismo que matou as bibliotecas gratuitas: todas partiam de um caminho de acesso anônimo que não existe mais.

IDs de operação GraphQL (doc_ids) são identificadores embutidos no bundle JavaScript do X que dizem ao backend qual operação executar. Buscar um perfil, pesquisar tweets e carregar uma timeline exigem, cada um, um identificador diferente. O X os rotaciona a cada duas a quatro semanas, você acompanha de oito a doze ao mesmo tempo, e não há documentação, então você faz engenharia reversa a partir do JavaScript minificado e repete tudo quinze dias depois. Um scraper dirigido por navegador contorna isso ao deixar a própria página pedir os doc_ids atuais.

Rate limits e detecção são a terceira camada. O X impõe cerca de 300 requisições por hora por IP em sessões de convidado. IPs de datacenter são marcados em uma ou duas requisições. O fingerprinting de TLS pega navegadores headless cuja pilha de rede não imita perfeitamente uma real, e a validação de cookies sinaliza padrões suspeitos de sessão. Se uma conta que você usa for marcada, nosso verificador de shadowban gratuito confirma em poucos segundos.

Essas defesas não ficaram paradas. A tabela abaixo é o registro do que o X mudou e quando, e é por isso que um guia de scraping com apenas doze meses já pode apontar você para ferramentas mortas.

A conclusão é que o X não é um alvo estável. Ele publica mudanças defensivas a cada duas a quatro semanas, em média, e qualquer scraper vira uma assinatura permanente de manutenção.

Método 1: scraping com navegador headless (com código) {#method-1-headless-browser-scraping-with-code}

A abordagem faça-você-mesmo mais comum automatiza um navegador real, carrega páginas do X e intercepta as respostas GraphQL que carregam os dados. Funciona porque roda o mesmo JavaScript que o X espera, então a própria página pede os doc_ids atuais e os dados renderizam como renderizariam para uma pessoa. Você nunca precisa rastrear IDs de operação na mão.

Aqui vai um exemplo mínimo em Python com Playwright que faz scraping de um único tweet capturando a chamada TweetResultByRestId em segundo plano:

from playwright.sync_api import sync_playwright
import json

def scrape_tweet(url: str) -> dict:
    xhr_calls = []

    def capture_response(response):
        if response.request.resource_type == "xhr":
            xhr_calls.append(response)

    with sync_playwright() as pw:
        browser = pw.chromium.launch(headless=True)
        page = browser.new_page()
        page.on("response", capture_response)
        page.goto(url)
        page.wait_for_selector("[data-testid='tweet']", timeout=15000)

        for xhr in xhr_calls:
            if "TweetResultByRestId" in xhr.url:
                data = xhr.json()
                return data["data"]["tweetResult"]["result"]

    return {}

tweet = scrape_tweet("https://x.com/elonmusk/status/1234567890")
print(json.dumps(tweet, indent=2))

O script sobe o Chromium, navega até um tweet, espera a renderização e então filtra as chamadas XHR de fundo pela que carrega os dados do tweet. Você recebe o objeto completo do tweet: texto, timestamps, contadores de engajamento, URLs de mídia e o perfil do autor. Os campos do tweet ficam aninhados sob uma chave legacy, então, em produção, você achata os que precisa (texto, created_at, favorite_count, retweet_count, reply_count, view_count) em vez de guardar a árvore bruta.

O mesmo padrão vale para outras partes do site: basta casar outra operação na URL do XHR. Perfis usam UserByScreenName, a timeline de um usuário usa UserTweets e a busca usa SearchTimeline (embora a busca exija sessão logada). Para perfis, você espera por UserByScreenName em vez do seletor do tweet e lê o objeto de usuário nessa resposta.

O que você consegue obter: perfis públicos, tweets individuais, respostas visíveis, quotes e mídia incorporada. Basicamente qualquer coisa que esteja na interface pública.

O que você não consegue obter sem login: contas protegidas, DMs, listas completas de seguidores e busca completa ou timelines longas. O scraping autenticado alcança essas coisas, mas arrisca banimentos.

O que é preciso para manter rodando. Proxies residenciais são inegociáveis, já que IPs de datacenter são bloqueados quase na hora; reserve de US$ 1 a US$ 3 por gigabyte e de US$ 50 a US$ 200 por mês, conforme o volume. Você precisa de spoofing de fingerprint, tamanhos de viewport realistas e pausas aleatórias parecidas com as humanas, além de lógica de retentativa para tokens que expiram no meio da sessão e endpoints GraphQL que retornam vazio quando os doc_ids são rotacionados. Isso funciona hoje e vai quebrar dentro de duas a quatro semanas da próxima atualização do X, então planeje de dez a quinze horas por mês para manter tudo vivo.

Método 2: bibliotecas Python de código aberto {#method-2-open-source-python-libraries}

Em vez de construir do zero, você pode usar uma biblioteca que embrulha a API interna do X. Algumas são mantidas ativamente e funcionam hoje; várias muito recomendadas estão mortas; e uma antiga escolha padrão está quebrada no repositório oficial. Aqui vai o quadro honesto, reverificado no GitHub e no PyPI em julho de 2026.

A coluna de status é o ponto central desta tabela, e ela muda. O Twikit foi por muito tempo a recomendação padrão porque é assíncrono, bem documentado e tinha a maior comunidade, mas o release publicado no PyPI quebrou com as mudanças de webpack e de transaction ID do X em 2026, e os usuários migraram para um fork mantido que preserva o mesmo import twikit. Se um tutorial ainda manda você rodar pip install twikit e esperar que funcione de primeira, confira antes a data e as issues abertas. Para coleta de dados somente leitura hoje, a escolha mais confiável é o twscrape.

twscrape foi feito exatamente para esse trabalho. Autentica com tokens ou cookies, guarda as sessões em um banco local e traz rotação de múltiplas contas embutida, então distribui as requisições entre um pool de contas e atravessa os rate limits mais rápido que um setup de conta única. Um exemplo de busca pela CLI dele cabe em uma linha, twscrape search "from:xdevelopers lang:en" --limit=20, e a API em Python espelha isso. As trocas a conhecer: é somente assíncrono, somente leitura por design e não tem retomada embutida, então uma extração grande de vários dias exige a sua própria lógica de checkpoint.

O cemitério (não perca seu tempo)

Se um tutorial recomenda alguma dessas como solução atual, a data dele entrega tudo. O cenário de scraping do X se renova rápido, e é exatamente por isso que datamos a tabela das que funcionam: uma biblioteca que rodava no trimestre passado pode estar morta neste.

O porém de toda biblioteca funcional

Cada biblioteca da tabela das que funcionam precisa de uma conta logada do X, e isso traz consequências. Nunca use sua conta pessoal, porque o X suspende contas com comportamento automatizado, e a verificação para novas contas de scraping ficou mais rígida. Para qualquer volume real, você precisa de várias contas dedicadas e de um sistema de rotação, continua precisando de proxies residenciais, e mesmo uma biblioteca mantida ativamente quebra quando o X publica uma atualização, momento em que você depende do tempo de resposta do mantenedor ou de alguém que faça um fork.

Método 3: scraping assistido por IA {#method-3-ai-assisted-scraping}

O scraping assistido por IA troca seletores CSS frágeis por um modelo de linguagem que lê a página e extrai o que você descreve em linguagem comum. A opção de código aberto mais conhecida é o ScrapeGraphAI, uma biblioteca Python em que você escreve um prompt como "pegue o texto, o autor e o número de curtidas de cada tweet" e ela descobre a estrutura sozinha, e depois se readapta quando o X muda o layout em vez de quebrar num elemento renomeado.

Essa é uma resposta real ao problema de manutenção, com trocas reais. O modelo ainda precisa chegar até a página, então você carrega os mesmos requisitos de proxy, de conta e de defesas antibot de qualquer outro método, e nenhum deles o LLM resolve. Cada extração passa a gastar tokens também, o que adiciona custo e latência e deixa a saída menos determinística que um parser fixo. Encaixa bem em prototipagem e em layouts que mudam com frequência, e encaixa mal em coleta barata, de alto volume e repetível, em que você quer custo previsível por registro. Se custo previsível e zero manutenção são o objetivo, uma API de dados estruturados é a versão mais limpa daquilo que o scraping com IA tenta alcançar.

Método 4: serviços gerenciados de scraping {#method-4-managed-scraping-services}

Serviços gerenciados rodam a infraestrutura de scraping por você. Você envia uma consulta ou uma URL, eles devolvem dados estruturados, e rotação de proxy, gestão de tokens e contorno das defesas antibot são problema deles. Os nomes que você vai comparar são Bright Data, Apify e Scrapfly, e o Scweet também oferece uma versão hospedada no Apify, com um plano gratuito pequeno. A vantagem é não ter código para manter nem proxies para administrar. As desvantagens são o custo em escala e a dependência do fornecedor: se o scraper deles quebra, você espera o conserto deles, e os modelos de preço variam de por tweet a por unidade de computação a por gigabyte de tráfego de proxy, o que torna o custo real por registro difícil de comparar pelo preço anunciado.

Essa é uma decisão grande o bastante para merecer o próprio detalhamento. Para custos reais por 1.000, confiabilidade e taxas escondidas de cada opção gerenciada, veja nossa comparação de scrapers de Twitter.

Como achar URLs de tweets e perfis para coletar {#how-to-find-tweet-and-profile-urls-to-scrape}

Todo método de scraping acima precisa de alvos: as URLs específicas de tweets e perfis que você quer extrair. A busca do próprio X está atrás de login, então a solução alternativa prática é o Google, que indexa tweets públicos. Uma consulta com site: costuma ser a forma mais rápida de montar uma lista de alvos sem conta.

Três padrões cobrem a maioria das necessidades. site:x.com inurl:status <keyword> traz tweets individuais sobre um tema. site:x.com <name> encontra páginas de perfil de uma pessoa ou marca. Somar as ferramentas de intervalo de datas do Google filtra por posts recentes. A única ressalva honesta é que o índice do Google fica de horas a dias atrás do X em tempo real, então, para conteúdo de última hora, ele não estará atualizado; mas, para montar uma lista de perfis e posts a coletar, funciona bem. Se você precisa de descoberta em tempo real em vez de uma lista estática, é exatamente aí que buscar por consulta ganha de rastrear páginas, e uma API de busca devolve os tweets correspondentes diretamente.

Quanto o scraping realmente custa {#what-scraping-actually-costs}

A maioria dos tutoriais cita o preço de tabela da ferramenta e para por aí. O custo real de fazer scraping do X é a ferramenta mais os proxies residenciais mais o tempo de desenvolvimento mais o custo recorrente das coisas quebrando. Aqui está o quadro completo das rotas.

A linha que decide é a manutenção. O tempo de desenvolvimento é a rubrica mais cara da lista, e ele não aparece até a primeira vez em que o X rotaciona os doc_ids e o seu pipeline emudece numa sexta-feira. Equipes com quem trabalhamos gastam rotineiramente de dez a quinze horas por mês para manter vivo um scraper próprio de X, mais a conta do proxy por cima. Como ordem de grandeza, extrair 10.000 tweets por automação de navegador dá cerca de 50 a 100 requisições e alguns dólares de tráfego de proxy residencial, antes de contar as horas. As ferramentas gratuitas não são gratuitas quando você põe preço no seu próprio tempo.

Método 5: uma API de dados somente leitura (sem scraping) {#method-5-a-read-only-data-api-no-scraping}

Se você leu até aqui, a conclusão honesta é que fazer scraping do X é possível, mas caro em tempo, dinheiro e esforço contínuo, e para muitos casos de uso você não precisa coletar nada. Uma API de dados do X somente leitura devolve a mesma informação por endpoints REST simples: perfis, tweets, busca, seguidores, engajamento, dados de comunidade, tudo como JSON limpo, uma chave de API no cabeçalho, sem proxies, sem guest tokens, sem doc_ids.

Aqui vai uma consulta de perfil com a API da Sorsa:

curl -H "ApiKey: YOUR_KEY" \
  "https://api.sorsa.io/v3/info?username=elonmusk"

Isso devolve o objeto de perfil completo em uma linha: ID, nome de usuário, nome de exibição, bio, contadores de seguidores e de seguindo, contador de tweets, status de verificação, imagens e data de criação. Compare com as mais de 20 linhas de Playwright acima, além da configuração de proxy, da gestão de tokens e da lógica de retentativa que aquele exemplo nem mostra.

A Sorsa cobre 40 endpoints em usuários, tweets, busca, seguidores, verificação, comunidades, listas e trends, com um limite fixo de 20 requisições por segundo e sem janelas por endpoint. O preço parte de US$ 0,02 por 1.000 tweets e US$ 0,01 por 1.000 perfis nos endpoints em lote, em que chamadas como /info-batch (até 100 perfis) e /tweet-info-bulk (até 100 tweets) contam, cada uma, como uma única requisição. As primeiras 100 requisições são grátis, sem cartão, você pode testar qualquer endpoint sem código no playground, e o início rápido de três minutos coloca a primeira chamada de pé sem aprovação. Vindo da API oficial do X, o guia de migração mapeia a troca endpoint por endpoint.

A troca é real e vale nomear: uma API é somente leitura, então não posta, não curte e não segue, e você depende do provedor em vez do seu próprio código. Para trabalho de leitura intensa que precisa continuar rodando, esse costuma ser justamente o ponto.

Na prática: um pipeline de monitoramento que parou de quebrar

Uma equipe de análise de uma fintech de médio porte chegou até nós rodando um scraper próprio em Playwright para monitoramento em tempo real de algumas centenas de contas de finanças e de concorrentes. Funcionava até parar de funcionar: toda vez que o X rotacionava os doc_ids, o pipeline emudecia, e um engenheiro perdia um dia refazendo a engenharia reversa dos novos identificadores e rotacionando proxies. Entre horas de desenvolvimento e proxies residenciais, o custo mensal real tinha passado de US$ 2.000 por dados que eles tratavam como rotina.

Eles moveram o lado de leitura para uma API de dados e mantiveram só as partes que eram de fato deles. O ralo recorrente de engenharia foi a zero, porque as mesmas chamadas REST devolviam o mesmo JSON todo dia, não importava o que o X mudasse por lá, e o gasto caiu para uma fração do total de proxy mais horas. A redução de custo é uma propriedade real de trocar o scraping por conta com proxies pela cobrança fixa por requisição; a redução de manutenção é simplesmente o que acontece quando você para de rodar um scraper. Mantemos o exemplo anônimo porque nomear um cliente e seus alvos de monitoramento pode expor os dois.

Qual método você deve usar? {#which-method-should-you-use}

Não existe um vencedor único. A escolha certa depende do seu volume, do seu orçamento e de quanta indisponibilidade você tolera.

Faça scraping com navegador headless quando quiser controle total da extração, estiver aprendendo scraping como habilidade ou o seu fluxo for genuinamente sob medida e nenhuma ferramenta o cobrir. Use uma biblioteca de código aberto quando quiser um começo mais rápido que o faça-você-mesmo e puder aceitar risco de banimento de conta e manutenção. Use um scraper gerenciado quando quiser terceirizar a infraestrutura e o uptime importar mais que o custo. Use uma API de dados somente leitura quando precisar de acesso de leitura confiável, não puder arcar com quebras semanais ou estiver entregando um produto em cima dos dados do X. E fique na API oficial do X para qualquer coisa que escreva, postar, DMs, seguir, já que nenhum scraper e nenhuma API de leitura fazem ações de escrita com segurança, além de dados de Ads e de compliance.

Para um olhar mais amplo sobre provedores, veja nosso guia de alternativas à API do Twitter (X); para quanto a API oficial custa hoje, nossa análise de preços da API do X; e, se você quer saber se o plano gratuito sobreviveu, a API do Twitter é gratuita em 2026.

Perguntas frequentes {#faq}

Ainda é possível fazer scraping do Twitter em 2026?

Sim, dados públicos do Twitter continuam acessíveis por scraping em 2026 sem a API oficial, mas os caminhos fáceis acabaram. As bibliotecas gratuitas que dependiam de acesso anônimo estão mortas, a navegação como convidado tem rate limit, e o X rotaciona seus guest tokens internos e identificadores GraphQL a cada duas a quatro semanas. Os métodos que funcionam hoje são automação de navegador headless, uma biblioteca de código aberto mantida em uma conta logada, um scraper gerenciado ou uma API de dados somente leitura.

Dá para fazer scraping do Twitter sem logar?

Dá, mas com limites pesados. Sem autenticação, o scraping com navegador headless alcança perfis públicos e tweets individuais, enquanto busca completa, timelines inteiras, threads profundas e listas de seguidores ficam restritas ou bloqueadas. Toda biblioteca de código aberto que dá acesso completo aos dados exige credenciais de conta ou tokens de sessão, que é o que destrava os dados completos.

Qual é a melhor ferramenta para fazer scraping do Twitter em 2026?

Depende do seu trabalho. Para coleta de dados somente leitura em alto volume, o twscrape é a biblioteca mantida mais confiável, com rotação de múltiplas contas embutida. Scweet e Tweety também funcionam. O release oficial do Twikit está quebrado pelas mudanças do X em 2026 e roda em um fork da comunidade, então verifique o status dele antes de contar com ele. Para acesso sem manutenção, sem proxies nem contas banidas, uma API de dados somente leitura como a Sorsa devolve os mesmos dados por endpoints REST, a partir de US$ 0,02 por 1.000 tweets, com as primeiras 100 requisições grátis.

Dá para fazer scraping do Twitter com Python?

Sim, o Python é a linguagem mais comum para isso. Você pode dirigir um navegador headless com Playwright e capturar as respostas GraphQL do X, ou usar uma biblioteca: twscrape para colheita de dados com múltiplas contas, Scweet para uma abordagem de cookies mais GraphQL ou Tweety para extrações leves. O Tweepy também existe, mas embrulha a API oficial paga em vez de fazer scraping. Se uma API encaixa melhor que um scraper, nosso guia da API do Twitter em Python percorre a rota REST.

É legal fazer scraping do Twitter?

Coletar dados genuinamente públicos é, em geral, lícito nos EUA, porque os tribunais entenderam que acessar dados públicos da web não viola a Computer Fraud and Abuse Act. Ainda assim, pode violar os Termos de Serviço do X, o que é questão contratual e não crime, e pode render banimento de conta ou de IP. Acessar dados não públicos cruza a linha da CFAA. Na União Europeia, o GDPR se aplica quando posts públicos contêm dados pessoais que você armazena ou processa. Isto é informativo, não é aconselhamento jurídico.

A API oficial do X ainda tem plano gratuito?

Não. O X descontinuou o plano gratuito e migrou para preço de pagamento por uso para novos desenvolvedores. Você compra créditos adiantado e paga por recurso: cerca de US$ 0,005 por post lido, US$ 0,010 por perfil de usuário e US$ 0,015 por post criado, com teto de 2 milhões de leituras de posts por mês em contas padrão. Nosso guia complementar sobre se a API do X é gratuita cobre as opções atuais.

Com que frequência o X quebra scrapers?

A cada duas a quatro semanas, em média. Os gatilhos usuais são mudanças em como os guest tokens são emitidos, rotações dos IDs de operação GraphQL e novas camadas de detecção antibot. Qualquer scraper, faça-você-mesmo ou baseado em biblioteca, precisa de atualizações regulares para continuar funcionando, e essa manutenção recorrente é o maior custo escondido da abordagem de scraping.

Como verificamos este guia {#how-we-verified-this-guide}

Este guia é construído sobre o nosso próprio trabalho operando uma API de dados do X e testando contra os endpoints ao vivo do X, além de uma revisão nova do estado atual de cada ferramenta. Nesta passada, reconferimos as bibliotecas de código aberto diretamente no GitHub e no PyPI para confirmar o que é mantido (twscrape, Scweet e Tweety estão ativas em 2026; snscrape, Twint e ntscraper não; o release oficial do Twikit está quebrado e roda em um fork da comunidade), lemos os Termos de Serviço do X em vigor desde 15 de janeiro de 2026 quanto à linguagem de scraping e de indenização predeterminada e usamos o resumo da EFF da decisão do Nono Circuito sobre a CFAA na seção de jurisprudência. O preço da nossa própria API vem da documentação da Sorsa. Os Termos de Serviço do X e o preço da API oficial do X foram reverificados em julho de 2026; o levantamento de bibliotecas de código aberto foi testado no mesmo mês. Bibliotecas e termos de plataforma mudam rápido, então reconfira na fonte qualquer coisa sensível ao tempo antes de confiar nela.