API de Listas do Twitter: obtenha membros, tweets, seguidores (2026)

Por Sorsa Editorial

Atualizado em julho de 2026: adicionamos a opção inicial de 100 requisições grátis, reformulamos o preço de Lista em torno das tarifas por 1.000 perfis e reconstruímos a comparação com a API oficial do X. A disponibilidade das Comunidades do X foi rechecada.

Em resumo: Uma Lista do X é um grupo público e curado de até 5.000 contas com a sua própria linha do tempo. Uma API de Listas retorna cada membro, cada assinante e um feed combinado de tweets desses membros em chamadas únicas. Fazer polling de uma Lista substitui fazer polling de cada conta, cortando o volume de requisições em cerca de 50 vezes para uma watchlist de 50 contas.

As Listas do X são uma das fontes de dados mais subutilizadas da plataforma. Uma Lista bem mantida é uma escalação curada à mão: o conjunto de fundadores de fintech de um analista, o conjunto de correspondentes de guerra de um jornalista, o conjunto de KOLs de cripto de uma corretora. Alguém já fez a pesquisa de audiência, e a Lista resultante é consultável como um único objeto.

Os endpoints por trás desse fluxo viviam só na API oficial do X, o que é viável se você está confortável com OAuth 2.0, cotas mensais de leitura de post e um preço que não escala para monitoramento contínuo. A Sorsa API, uma API alternativa do Twitter (X), expõe as Listas por três endpoints atrás de um único cabeçalho ApiKey: sem OAuth, sem revisão de app e um fixo de 20 requisições por segundo em todo plano. Como /list-members retorna até 200 perfis por requisição, a extração de Lista começa a partir de US$ 0,01 por 1.000 perfis nos planos fixos, então os padrões abaixo permanecem baratos em escala. Os pontos estratégicos (o que consultar, quando uma Lista bate o polling bruto, como pensar sobre custo) são gerais, e o código é Python simples que você pode rodar como está.

Índice

• O que é uma Lista do X, e o que você pode puxar dela?
• Por que fazer polling de uma Lista em vez de cada conta?
• Os três endpoints de Lista
• O que a API de Listas retorna?
• Para que as Listas do X servem além do monitoramento?
• Uma nota sobre as Comunidades do X
• API de Listas do Twitter contra a API oficial do X
• Como configurar uma Lista que você possa monitorar
• Código: puxando dados de Lista em Python
• Como isso fica na prática
• Primeiros passos
• Perguntas frequentes

O que é uma Lista do X, e o que você pode puxar dela? {#what-is-an-x-list-and-what-can-you-pull-from-it}

Uma Lista do X é uma coleção pública ou privada de até 5.000 contas com a sua própria linha do tempo mostrando apenas posts dos membros dela. Qualquer um pode criar uma, e qualquer um com acesso pode assinar. Por uma API você pode extrair duas audiências diferentes de uma Lista pública: os membros dela e os assinantes dela.

Esses dois grupos sinalizam coisas diferentes, e ambos são extraíveis:

• Membros são as contas na Lista. Eles são quem o curador achou que valia a pena acompanhar.
• Assinantes (seguidores da Lista) são usuários que escolheram seguir a Lista para lê-la. Eles ativamente optaram por aquele tópico.

Listas privadas não são alcançáveis por nenhuma API, oficial ou de terceiros. Tudo abaixo assume que a Lista é pública e resolve quando aberta em um navegador deslogado.

Por que fazer polling de uma Lista em vez de cada conta? {#why-poll-a-list-instead-of-each-account}

Fazer polling de uma Lista colapsa muitas requisições por conta em uma. A razão pela qual as Listas importam para a engenharia, não só para a curadoria, é o volume de requisições.

Suponha que você acompanhe 50 contas, digamos uma watchlist do setor fintech, e faça polling de cada uma a cada 10 segundos. São 50 requisições por ciclo, 8.640 ciclos por dia, e 432.000 requisições por dia, cerca de 13 milhões por mês. Nenhum plano de nenhum provedor é feito para isso.

Construa uma Lista das mesmas 50 contas e faça polling de um único feed de tweets em vez disso. Uma requisição por ciclo no mesmo intervalo de 10 segundos são 8.640 requisições por dia, cerca de 259.000 por mês. Você pega os mesmos posts, muitas vezes com menor latência, porque as linhas do tempo de Lista são cacheadas agressivamente pelo próprio X.

Uma chamada de Lista substitui 50 chamadas por conta, uma redução de 50x que escala com a watchlist: uma Lista de 200 contas é uma redução de 200x.

Na prática você raramente precisa de uma cadência de 10 segundos. Fazer polling de uma Lista a cada 30 segundos são cerca de 86.000 requisições por mês, o que fica confortavelmente dentro do plano Pro da Sorsa a US$ 199 por 100.000 requisições. Este é o padrão dominante nos pipelines de monitoramento em tempo real que configuramos com clientes rodando social listening no Twitter e no X.

Os três endpoints de Lista {#the-three-list-endpoints}

A Sorsa expõe três endpoints de Lista, todos paginados por next_cursor. Quando o cursor volta nulo ou ausente, você chegou ao fim.

Para pesquisa de audiência, /list-followers é muitas vezes mais útil do que /list-members: os membros são quem o curador escolheu, enquanto os assinantes se autoidentificaram como interessados no tópico. Se você também precisa do próprio grafo de seguidores e de seguindo de cada conta, esse é um trabalho separado coberto pelos endpoints de listas de seguidores e de seguindo, não pelos endpoints de Lista aqui.

O que a API de Listas retorna? {#what-does-the-list-api-return}

Os endpoints de Lista retornam JSON limpo sem cobrança separada pelo perfil do autor aninhado. /list-members e /list-followers retornam um array users de objetos de perfil completos mais um next_cursor. /list-tweets retorna um array tweets mais um next_cursor, e cada tweet carrega o perfil completo do autor inline sem custo extra.

Estes são os principais campos em cada objeto de perfil de membro ou assinante:

Cada tweet em uma resposta /list-tweets carrega texto, métricas e o autor. Os principais campos:

Uma resposta /list-tweets enxugada fica assim:

{
  "tweets": [
    {
      "id": "1782368585664626774",
      "full_text": "Shipping the new pricing today.",
      "created_at": "2026-05-18T10:30:00Z",
      "lang": "en",
      "likes_count": 200,
      "retweet_count": 50,
      "reply_count": 10,
      "view_count": 10000,
      "is_reply": false,
      "is_quote_status": false,
      "user": {
        "id": "44196397",
        "username": "founder",
        "display_name": "A Founder",
        "followers_count": 100000,
        "verified": true,
        "created_at": "2009-06-02T20:12:29Z"
      },
      "entities": []
    }
  ],
  "next_cursor": "DAABCgAB..."
}

Como o perfil do autor é embutido em cada tweet, uma única chamada de feed de Lista te dá tanto o conteúdo quanto as pessoas por trás dele, sem uma segunda consulta e sem cobrança por perfil. As definições completas de campo estão na documentação de Listas e Comunidades.

Para que as Listas do X servem além do monitoramento? {#what-are-x-lists-good-for-beyond-monitoring}

Além do monitoramento em tempo real, as Listas permitem vários padrões de pesquisa que de outro modo dariam muito mais trabalho:

Descoberta de especialistas de nicho. Jornalistas e analistas curam Listas com nomes como "AI Safety Researchers" ou "DeFi Founders". A escalação de membros é uma lista curta chancelada por especialistas. Puxe-a uma vez, ordene por contador de seguidores ou por engajamento recente, e você tem uma lista de alvos de prospecção em minutos.

Análise de sobreposição de audiência. Puxe os membros de duas Listas concorrentes no mesmo nicho. A interseção mostra as escolhas de consenso; a diferença mostra os pontos cegos de cada curador. É mais rápido do que rodar uma análise de concorrentes do zero.

Sentimento de setor. Puxe o feed de uma Lista de setor de 100 contas diariamente, empurre o texto por qualquer modelo de sentimento e plote a média móvel. Você obtém um sinal sem fazer nenhuma descoberta de contas antes.

Herança de audiência. Puxe os assinantes de uma Lista de setor mantida por um curador respeitado. Estas são pessoas que optaram pelo tópico, um ponto de partida muito mais limpo para encontrar leads qualificados no Twitter do que uma extração genérica de seguidores.

Uma nota sobre as Comunidades do X {#a-note-on-x-communities}

As Comunidades do X são grupos baseados em tópico e de adesão opcional: os membros escolhem entrar, o que torna a escalação um sinal de interesse forte em vez da escolha de um curador. A Sorsa as expõe por /community-members, /community-tweets e /community-search-tweets, todos endpoints POST que seguem o mesmo padrão de paginação que os endpoints de Lista.

Uma nota de status importa aqui. O X anunciou em abril de 2026 que planejava aposentar as Comunidades, citando um uso abaixo de 0,4% das contas e uma fatia desproporcional de spam da plataforma, como o TechCrunch reportou ao lado de uma extensão do prazo original. A linha do tempo desde então mudou, e em junho de 2026 as Comunidades e os endpoints de Comunidade ainda retornam dados. Trate o recurso como em risco: se você constrói qualquer coisa durável, construa em Listas, que não estão marcadas para remoção. Se você precisa extrair uma Comunidade agora, o padrão é idêntico ao código de Lista abaixo, usando POST com community_id ou community_link.

API de Listas do Twitter contra a API oficial do X {#twitter-list-api-vs-the-official-x-api}

A API oficial do X de fato expõe endpoints de Lista. Qual usar depende principalmente de quanto volume você precisa e de quanto OAuth você está disposto a manter. A Sorsa API é o nosso produto, e a comparação abaixo usa números que você pode verificar na documentação de desenvolvedor do X e no nosso próprio detalhamento de preços da API do X. Teste qualquer provedor contra a sua própria carga antes de se comprometer.

A diferença central é a unidade de cobrança. A Sorsa cobra uma requisição por chamada não importa quantos perfis ou tweets voltem, então os até 200 perfis em uma página de Lista e os perfis de autor embutidos em um feed de Lista não custam nada extra. A API oficial do X cobra cada um deles como uma leitura de recurso à parte, que é o que faz o monitoramento contínuo de Lista somar. Em cargas de Lista de leitura intensa a Sorsa roda até 50x mais barato. O detalhamento de rate limit cobre por que o polling contínuo é onde os dois modelos mais divergem.

O veredito:

• Extração e monitoramento de Lista de leitura intensa: Sorsa. O preço fixo por requisição mais até 200 perfis por chamada mantêm o polling contínuo barato, e uma única chave de API basta para começar.
• Postar, DMs, Ads API ou streaming filtrado: a API oficial do X, já que essas são capacidades first-party de escrita e de stream que a Sorsa não oferece.

Como configurar uma Lista que você possa monitorar {#how-to-set-up-a-list-you-can-monitor}

Você só pode puxar dados de Listas que existem, e toda API neste ponto é somente leitura. Para configurar uma Lista que você possa monitorar, faça isso uma vez na interface web do X:

1. Vá em x.com/lists e selecione "Criar nova lista".
2. Marque a Lista como pública. Listas privadas não são acessíveis por API por ninguém.
3. Adicione até 5.000 contas. Você pode colar @s, buscar ou importar em massa.
4. Copie o ID numérico da Lista da URL: em https://x.com/i/lists/1234567890, o ID é 1234567890.
5. Faça polling do feed da Lista contra aquele ID no intervalo que o seu orçamento de latência permitir.

A Lista não precisa ser sua para ser consultável. Se a Lista pública de outra pessoa já cobre o seu tópico, pegue o ID da URL dela. Se você está construindo um pipeline de monitoramento privado e não quer as suas contas rastreadas visíveis sob a sua identidade principal, crie a Lista sob uma conta separada com um nome genérico; ela permanece pública para que a API possa alcançá-la, mas não fica atrelada ao seu @ real.

Código: puxando dados de Lista em Python {#code-pulling-list-data-in-python}

Os exemplos usam Python simples com requests. Sem SDK, sem dança de autenticação. Eles assumem Python 3.9 ou mais novo e uma chave de API em uma variável de ambiente. Todo endpoint paginado retorna next_cursor; quando ele é nulo ou está ausente, você terminou.

import os
import time
import requests

API_KEY = os.environ["SORSA_API_KEY"]
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}

Extraindo membros de Lista

def get_list_members(list_id, max_pages=50):
    """Fetch member profiles from a public X List. Up to 200 per page."""
    members, cursor = [], None

    for _ in range(max_pages):
        params = {"list_id": list_id}
        if cursor:
            params["next_cursor"] = cursor

        r = requests.get(f"{BASE}/list-members", headers=HEADERS, params=params, timeout=30)
        r.raise_for_status()
        data = r.json()

        members.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.1)

    return members


members = get_list_members("1234567890")
print(f"Pulled {len(members)} members")

for m in members[:5]:
    bio = (m.get("description") or "")[:60]
    print(f"@{m['username']} ({m['followers_count']:,} followers): {bio}")

Uma Lista de 5.000 membros totalmente povoada leva cerca de 25 requisições para extrair, já que o endpoint retorna até 200 perfis por chamada.

Extraindo assinantes de Lista

Os assinantes (pessoas que seguem a Lista para lê-la, não os membros nela) usam o parâmetro list_link, que aceita ou a URL completa ou apenas o ID numérico.

def get_list_followers(list_link, max_pages=50):
    """Users who subscribe to a public X List."""
    followers, cursor = [], None

    for _ in range(max_pages):
        params = {"list_link": list_link}
        if cursor:
            params["next_cursor"] = cursor

        r = requests.get(f"{BASE}/list-followers", headers=HEADERS, params=params, timeout=30)
        r.raise_for_status()
        data = r.json()

        followers.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.1)

    return followers


subs = get_list_followers("https://x.com/i/lists/1234567890")
print(f"{len(subs)} accounts subscribe to this List")

Puxando tweets de uma Lista

Este é o endpoint de monitoramento: cerca de 20 tweets por chamada, ordenados cronologicamente entre todos os membros.

def get_list_tweets(list_id, max_pages=10):
    """Recent tweets from all members of a List, combined feed."""
    tweets, cursor = [], None

    for _ in range(max_pages):
        params = {"list_id": list_id}
        if cursor:
            params["next_cursor"] = cursor

        r = requests.get(f"{BASE}/list-tweets", headers=HEADERS, params=params, timeout=30)
        r.raise_for_status()
        data = r.json()

        tweets.extend(data.get("tweets", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.1)

    return tweets


feed = get_list_tweets("1234567890", max_pages=20)
print(f"Collected {len(feed)} tweets")

for t in feed[:5]:
    likes = t.get("likes_count", 0)
    print(f"@{t['user']['username']} ({likes} likes): {t['full_text'][:80]}")

Para monitoramento contínuo, rode isto em um cron ou loop asyncio no intervalo que couber no seu orçamento de latência. Fazer polling a cada 30 a 60 segundos é suficiente para tudo, exceto sinais de trading.

Exportando para CSV

import csv

def export_users_to_csv(users, path):
    fields = ["id", "username", "display_name", "description",
              "followers_count", "tweets_count", "verified", "location"]

    with open(path, "w", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=fields)
        writer.writeheader()
        for u in users:
            writer.writerow({
                "id": u.get("id", ""),
                "username": u.get("username", ""),
                "display_name": u.get("display_name", ""),
                "description": (u.get("description") or "").replace("\n", " "),
                "followers_count": u.get("followers_count", 0),
                "tweets_count": u.get("tweets_count", 0),
                "verified": u.get("verified", False),
                "location": u.get("location", ""),
            })

    print(f"Wrote {len(users)} rows to {path}")


export_users_to_csv(get_list_members("1234567890"), "members.csv")

O mesmo padrão funciona para assinantes. Para tweets, troque a lista de campos por id, full_text, created_at, likes_count, retweet_count e o username de user.

Tratamento de retry e de rate limit

Qualquer coisa que você rode em uma programação precisa de tratamento mínimo de erro. O rate limit fixo da Sorsa é de 20 requisições por segundo. Se você o excede, você recebe um 429; faça backoff e tente de novo.

def request_with_retry(method, url, max_attempts=5, **kwargs):
    for attempt in range(max_attempts):
        r = requests.request(method, url, **kwargs)

        if r.status_code == 429:
            time.sleep(2 ** attempt)
            continue

        if r.status_code >= 500:
            time.sleep(1 + attempt)
            continue

        r.raise_for_status()
        return r

    raise RuntimeError(f"Failed after {max_attempts} attempts: {url}")

Coloque isto no lugar de requests.get em qualquer função acima. Para trabalhos de longa duração, registre o cursor entre as páginas para poder retomar na falha sem refazer trabalho. Mais padrões estão em otimizando o uso da API.

Como isso fica na prática {#what-this-looks-like-in-practice}

Uma pequena equipe de análise com quem trabalhamos, cerca de dez pessoas construindo sinais para uma mesa de trading, estava monitorando cerca de 120 KOLs de cripto fazendo polling de cada conta por conta própria. A abordagem por conta era ao mesmo tempo cara na API oficial e lenta para reagir. Mover as mesmas contas para uma única Lista pública e fazer polling de um feed substituiu 120 extrações por conta por ciclo por uma, um corte de 120x no volume de requisições, e deu a eles uma leitura mais antecipada de tom em mudança do que esperar por rastreadores de sentimento de terceiros agregados. Os custos de dados seguiram o padrão geral que qualquer equipe de leitura intensa vê ao sair da API oficial: até 50x mais barato pela mesma cobertura. A vitória foi estrutural, não um truque: um feed de Lista em vez de 120 linhas do tempo.

Primeiros passos {#getting-started}

Pegue uma chave de API no painel da Sorsa, aponte-a para uma Lista que você já segue no X, e você está coletando dados estruturados em poucos minutos. Toda chave nova inclui 100 requisições grátis, única vez e sem cartão, o bastante para puxar até 20.000 perfis de membros de Lista ou rodar um loop de monitoramento antes de você se comprometer. O Playground da API deixa você testar cada endpoint sem escrever código primeiro, e a extração de Lista nos planos de preço fixos começa a partir de US$ 0,01 por 1.000 perfis, com as mesmas 20 requisições por segundo em todo nível. Se você está saindo da API oficial do X e quer um mapa endpoint por endpoint, o guia de migração percorre as equivalências.

Perguntas frequentes {#faq}

Dá para extrair membros de uma Lista privada do X?

Não. Listas privadas do X não são acessíveis por nenhuma API, oficial ou de terceiros. A Lista precisa ser pública, e a URL dela precisa resolver quando aberta em um navegador deslogado. Qualquer um alegando puxar dados de Lista privada ou está enganado ou planejando usar mal uma conta logada. Tudo descrito neste guia assume uma Lista pública.

Qual é o tamanho máximo de Lista do X que você pode extrair?

O X limita as Listas a 5.000 membros. O endpoint list-members da Sorsa pagina em até 200 perfis por requisição, então uma Lista completa de 5.000 membros leva cerca de 25 chamadas para extrair de ponta a ponta. Não há teto oculto além do próprio limite da plataforma de 5.000 membros.

Como achar um ID de Lista pela URL dela?

As URLs de Lista do X ficam como https://x.com/i/lists/1234567890, onde o valor numérico no fim é o ID da Lista. Algumas URLs mais antigas usam a forma x.com/username/lists/slug; abrir esse link redireciona para a versão numérica, e o número na URL resultante é o ID que você passa à API.

As Comunidades do X ainda funcionam pela API?

Em junho de 2026, sim. O X anunciou em abril de 2026 que planejava aposentar as Comunidades, citando baixo uso e alto spam, e o corte inicialmente anunciado desde então mudou, mas o recurso e os endpoints de Comunidade ainda retornam dados. Trate as Comunidades como em risco e construa o monitoramento durável em Listas, que não estão marcadas para remoção.

Fazer polling de uma Lista é mais eficiente do que chamar a API uma vez por conta?

Sim, e esta é a principal razão pela qual as Listas importam para a engenharia. Construir uma Lista pública e fazer polling de um único feed de tweets substitui uma requisição por conta por ciclo. Para uma watchlist de 50 contas na Sorsa, isso é cerca de 50 vezes menos requisições do que fazer polling de cada conta separadamente, e a economia escala com o número de contas na Lista.

Dá para obter tweets históricos de uma Lista, não apenas os recentes?

Um feed de tweets de Lista retorna a linha do tempo combinada recente dos membros dela, indo tão para trás quanto aquela linha do tempo estiver disponível. Para histórico profundo de uma conta específica, puxe a própria linha do tempo daquela conta; na Sorsa o endpoint user-tweets pagina de volta até os primeiros posts de uma conta sem o teto de 3.200 tweets. Listas são para monitoramento, extrações por conta são para arquivos.

Quanto custa puxar dados de Lista comparado com a API oficial do X?

A Sorsa cobra um fixo de uma requisição por chamada de API independentemente de quantos perfis ou tweets voltem, então a extração de Lista começa a partir de US$ 0,01 por 1.000 perfis nos planos fixos, e toda chave nova inclui 100 requisições grátis para experimentar primeiro. A API oficial do X cobra por recurso buscado no pagamento por uso, então uma única leitura de Lista que retorna muitos usuários e tweets é cobrada por item. Em cargas de Lista de leitura intensa a Sorsa roda até 50x mais barato.

IDs de Lista da era antiga do Twitter v1.1 ainda funcionam?

Sim, contanto que a Lista ainda seja pública e carregue na web. IDs de Lista criados nos dias do Twitter v1.1 permanecem válidos na plataforma X atual e em APIs de terceiros como a Sorsa. O rebrand de Twitter para X não invalidou IDs de Lista existentes nem mudou o formato numérico deles.

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

Este guia se apoia no trabalho prático da nossa equipe operando os endpoints de Lista e de Comunidade da Sorsa, na documentação ao vivo da Sorsa API v3 e na própria documentação de desenvolvedor do X. A linha do tempo de aposentadoria das Comunidades do X tem fonte no TechCrunch; a disponibilidade de Comunidade foi checada diretamente no X. As comparações de preço e de rate limit foram reverificadas contra o nosso guia de preços da API do X de 2026 e as páginas oficiais de preço de desenvolvedor do X. Verificado pela última vez em 6 de julho de 2026.