API de seguidores do Twitter: obtenha seguidores e seguindo (2026)

Por Sorsa Editorial

Atualizado em julho de 2026: adicionamos a opção inicial de 100 requisições grátis, reformulamos o preço da Sorsa em torno da tarifa por 1.000 perfis e atualizamos os custos da API oficial do X para a tabela de tarifas atual por recurso.

Em resumo: A API de seguidores do Twitter (X) recupera as contas que seguem um usuário e as contas que esse usuário segue. A API oficial do X expõe GET /2/users/:id/followers e GET /2/users/:id/following, retornando objetos de usuário paginados com metadados completos de perfil. Cada endpoint cobra por objeto de usuário retornado, então o custo de uma lista de seguidores escala com o tamanho da conta.

Se você já tentou puxar uma lista de seguidores do X (antigo Twitter) em qualquer escala significativa, bateu em uma de duas paredes. Ou a interface web para de carregar em silêncio depois de algumas centenas de perfis, ou você se cadastra na API oficial do X e descobre que "buscar 100.000 seguidores" pode significar uma fatura de quatro dígitos. Nenhuma das duas é viável para os trabalhos para os quais as pessoas de fato precisam de dados de seguidores: inteligência competitiva, geração de leads, descoberta de influenciadores, pesquisa acadêmica, verificação de campanha.

Este é o passo a passo orientado a desenvolvedores: os endpoints, o modelo de autenticação, os padrões de produção. Se você ainda não escolheu uma ferramenta e quer pesar acesso via API contra extensões de navegador, scrapers caseiros e a exportação nativa de dados do X, nossa comparação de métodos para extrair seguidores do Twitter cobre esses tradeoffs primeiro. O resto deste guia assume que você já se decidiu pela rota da API.

A Sorsa API, um provedor alternativo de API do Twitter (X), lida com os mesmos dados que os endpoints oficiais com uma estrutura de custo diferente. Os endpoints /followers e /follows dela retornam até 200 perfis de usuário completos por requisição atrás de um único cabeçalho ApiKey, rodam a um fixo de 20 requisições por segundo sem revisão de app e cobram por requisição em vez de por objeto de usuário. Essa última diferença é a história inteira para dados de seguidores em escala, e as seções abaixo percorrem o porquê, com os endpoints oficiais, o cálculo do preço e Python e JavaScript de copiar e colar.

Índice

1. O que a API de seguidores do Twitter retorna
2. Quanto custa a API oficial do X para seguidores em 2026?
3. Cobrança por recurso contra por requisição
4. Os endpoints de seguidores e de seguindo da Sorsa
5. Buscando uma página de seguidores
6. Paginando por uma lista completa de seguidores
7. Padrões de produção que importam em escala
8. Por que /verified-followers existe como um endpoint separado
9. Casos de borda que vão te pegar
10. Quando a API oficial do X ainda faz sentido
11. Perguntas frequentes
12. Primeiros passos

O que a API de seguidores do Twitter retorna {#what-the-twitter-followers-api-returns}

A API de seguidores do Twitter (X) retorna uma lista paginada de objetos de usuário, um por seguidor, com cada objeto carregando o perfil completo daquele seguidor, e não apenas um @. Uma única requisição de seguidores é, na prática, uma consulta de perfil em massa com um filtro de relação aplicado. Para cada seguidor você tipicamente obtém os mesmos campos que obteria de uma consulta de perfil direta.

• ID numérico de usuário estável e @ atual
• Nome de exibição, bio, URL da imagem de perfil, URL do banner
• Contador de seguidores, contador de seguindo, contador de tweets
• Data de criação da conta
• String de localização (livre, não validada)
• Status de verificado (Blue, Gold, Gray)
• Flag de protegido/privado
• URLs encontradas na bio
• IDs de tweet fixado

Essa riqueza importa mais do que parece. Com uma requisição de lista de seguidores você não está apenas coletando @s; está obtendo os dados necessários para qualificar, segmentar ou filtrar a audiência sem uma segunda rodada de consultas de perfil.

A API oficial do X divide isso entre dois endpoints:

A Sorsa expõe o mesmo par como GET /v3/followers e GET /v3/follows, mais um terceiro endpoint utilitário, GET /v3/verified-followers, que retorna apenas contas verificadas (mais sobre por que ele existe abaixo).

Quanto custa a API oficial do X para seguidores em 2026? {#how-much-does-the-official-x-api-cost-for-followers-in-2026}

No modelo de pagamento por uso da API do X, as leituras de seguidores e de seguindo são cobradas por objeto de usuário retornado, a US$ 0,010 por recurso para qualquer conta que não seja a sua. Uma lista de seguidores de 100.000 contas são 100.000 recursos cobráveis, cerca de US$ 1.000, não importa quão poucas requisições você usou para paginá-la. Este é o detalhe que a maioria dos guias mais antigos ignora, porque foram escritos antes das mudanças de preço de 2026.

O modelo chegou em dois passos. O X mudou para pagamento por uso como padrão para novos desenvolvedores em fevereiro de 2026: sem plano gratuito, sem assinatura fixa Basic ou Pro, apenas créditos comprados no Developer Console e cobrados por chamada. Depois, em 20 de abril de 2026, o X cortou as "Owned Reads" (requisições dos dados da sua própria conta) para US$ 0,001 por recurso, enquanto as leituras de qualquer outra conta permaneceram na tarifa padrão. Segundo a comunidade de desenvolvedores do X, você é cobrado por recurso: uma conta de usuário com 1.000 seguidores a US$ 0,010 cada dá US$ 10, cobrado por objeto de usuário retornado, não por requisição.

Esta é a pegadinha das "Owned Reads". Buscar a lista de seguidores da sua própria conta de desenvolvedor agora é barato. Buscar os seguidores de um concorrente, de um influenciador ou de uma fonte de leads é a leitura não-própria padrão, cobrada por objeto de usuário. O teto de 2 milhões por mês que o X aplica às leituras de post não governa as leituras de seguidores, que são cobradas puramente por recurso.

Divulgação: A Sorsa API é o nosso produto. Os números da API oficial usam o preço publicado do X, onde as leituras não-próprias são cobradas por recurso retornado e as leituras próprias são US$ 0,001 por recurso, na tarifa de leitura de usuário de US$ 0,010 por recurso vigente em junho de 2026; o seu custo exato pode variar com o tratamento de excedente e qualquer contrato negociado. Recomendamos testar qualquer provedor contra a sua carga real antes de se comprometer.

Cobrança por recurso contra por requisição {#per-resource-vs-per-request-billing}

A diferença entre cobrança por recurso e por requisição é o que decide o custo dos dados de seguidores, não a tarifa de manchete. A API oficial do X conta cada objeto de usuário em uma resposta como um recurso cobrável separado, então uma requisição que retorna 1.000 seguidores custa o mesmo que 1.000 consultas individuais. Uma API de tarifa fixa como a Sorsa conta a requisição inteira como uma unidade contra uma cota mensal, não importa quantos usuários voltem nela.

Para extração de seguidores essa lacuna se compõe rápido, porque os endpoints de seguidores retornam muitos objetos por chamada. Na API oficial, uma lista de 100.000 seguidores são 100.000 recursos a US$ 0,010 cada. Na Sorsa, a mesma lista são cerca de 500 requisições (200 perfis por requisição) contra uma cota mensal, cerca de US$ 1,00 no plano Pro. O formato dos dados é o mesmo; a unidade pela qual você paga, não.

Esta é a razão estrutural pela qual existe um mercado de API do Twitter de terceiros para dados de seguidores. A API oficial tem preço bom quando você só lê a sua própria conta. Para todo o resto, a cobrança por recurso joga contra você, e um modelo por requisição é a alavanca que traz o custo para baixo. Para o detalhamento completo entre provedores, veja nosso guia de preços da API do Twitter.

Os endpoints de seguidores e de seguindo da Sorsa {#the-sorsa-follower-and-following-endpoints}

Os endpoints de seguidores da Sorsa são três requisições GET autenticadas com um único cabeçalho ApiKey, sem fluxo OAuth, sem revisão de app e sem rotação de bearer token. A documentação completa de seguidores e seguindo cobre o schema de resposta e o comportamento de paginação em profundidade. A versão curta:

• GET /v3/followers retorna contas que seguem o usuário especificado.
• GET /v3/follows retorna contas que o usuário especificado está seguindo.
• GET /v3/verified-followers retorna o mesmo formato que /followers, mas apenas contas verificadas Blue, Gold e Gray.

Você passa um de três identificadores de usuário como parâmetro de query, mais um cursor de paginação opcional:

Cada página retorna até 200 objetos de usuário, entre os maiores rendimentos por requisição disponíveis. A API oficial do X limita cada chamada a 1.000 objetos de usuário mas cobra por cada um deles; a Sorsa retorna 200 por requisição e conta o lote inteiro como uma única requisição contra a sua cota.

Buscando uma página de seguidores {#fetching-one-page-of-followers}

A menor chamada funcional contra o endpoint /followers é um HTTP GET com um nome de usuário e a sua chave de API. Uma requisição, uma resposta, sem dança de autenticação.

cURL

curl "https://api.sorsa.io/v3/followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

Python

import requests

resp = requests.get(
    "https://api.sorsa.io/v3/followers",
    headers={"ApiKey": "YOUR_API_KEY"},
    params={"username": "stripe"},
)
for user in resp.json().get("users", []):
    print(f"@{user['username']} - {user.get('description', '')[:80]}")

JavaScript (Node.js ou navegador)

const resp = await fetch(
  "https://api.sorsa.io/v3/followers?username=stripe",
  { headers: { "ApiKey": "YOUR_API_KEY" } }
);
const { users } = await resp.json();
users.forEach((u) =>
  console.log(`@${u.username} - ${u.description?.slice(0, 80) ?? ""}`)
);

Para buscar as contas que um usuário está seguindo, troque /followers por /follows. O formato do parâmetro e a estrutura da resposta são idênticos. Se você quiser ver a resposta antes de escrever qualquer código, a ferramenta de Seguidores Recentes renderiza os últimos 20 seguidores de qualquer conta pública no seu navegador, e o Playground da API deixa você chamar qualquer endpoint sem escrever uma linha.

Paginando por uma lista completa de seguidores {#paginating-through-a-complete-follower-list}

Para recuperar uma lista de seguidores além da primeira página, você percorre páginas usando o valor next_cursor retornado em cada resposta, passando-o de volta na próxima requisição até ele voltar nulo ou ausente. Uma requisição retorna até 200 usuários na Sorsa, então uma lista completa é um loop sobre essas páginas.

Aqui vai um loop completo, com formato de produção, em Python. Ele lida com paginação, rate limiting e um teto rígido de páginas para que uma extração descontrolada não drene em silêncio a sua cota:

import requests
import time

API_KEY = "YOUR_API_KEY"

def get_all_followers(username, max_pages=100):
    """Fetch the complete follower list of a public account."""
    all_users = []
    cursor = None

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

        resp = requests.get(
            "https://api.sorsa.io/v3/followers",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        )
        resp.raise_for_status()
        data = resp.json()

        users = data.get("users", [])
        all_users.extend(users)
        print(f"Page {page + 1}: {len(users)} followers (total: {len(all_users)})")

        cursor = data.get("next_cursor")
        if not cursor:
            print("Reached end of list.")
            break

        # Sorsa's rate limit is 20 req/s. 50ms between calls is safe.
        time.sleep(0.05)

    return all_users


followers = get_all_followers("stripe", max_pages=100)
print(f"\nTotal followers collected: {len(followers)}")

No rate limit de 20 requisições por segundo, isso dá cerca de 4.000 seguidores por segundo de tempo real. Uma conta de 100.000 seguidores leva cerca de 25 segundos. Uma conta de um milhão de seguidores leva cerca de quatro minutos. O mesmo padrão de cursor se aplica a todo outro endpoint paginado da API.

Para uma lista de seguindo, troque /followers por /follows; todo o resto permanece idêntico. Uma função auxiliar unificada que lida com ambos:

def get_user_graph(username, endpoint, max_pages=100):
    """endpoint should be 'followers' or 'follows'."""
    all_users = []
    cursor = None
    for _ in range(max_pages):
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = requests.get(
            f"https://api.sorsa.io/v3/{endpoint}",
            headers={"ApiKey": API_KEY},
            params=params,
            timeout=30,
        ).json()
        all_users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            break
        time.sleep(0.05)
    return all_users

Padrões de produção que importam em escala {#production-patterns-that-matter-at-scale}

Um loop arrumadinho funciona em um notebook. Rodar a extração de seguidores dentro de um pipeline real (cron jobs, varreduras de múltiplas contas, enriquecimento downstream) faz emergir um conjunto diferente de problemas. Estes são os padrões que buscamos assim que o loop básico funciona.

Trate a resposta 429 de forma limpa

A Sorsa retorna 429 Too Many Requests quando você excede o limite de 20 req/s. A correção é curta: espere um segundo, tente de novo. Não há penalidade por atingir o limite e nem token bucket para descer. Um wrapper de encaixe:

import time
import requests

def get_with_retry(url, params, headers, max_retries=5):
    for attempt in range(max_retries):
        resp = requests.get(url, params=params, headers=headers, timeout=30)
        if resp.status_code == 429:
            # Rate limited. Back off and retry.
            time.sleep(1.0 + attempt * 0.5)
            continue
        if resp.status_code >= 500:
            # Transient server error. Exponential backoff.
            time.sleep(2 ** attempt)
            continue
        resp.raise_for_status()
        return resp.json()
    raise RuntimeError(f"Failed after {max_retries} retries")

Se o seu loop já dorme 50 ms entre chamadas, você raramente vai ver um 429. Eles aparecem principalmente quando você paraleliza entre contas. A documentação de rate limits descreve exatamente o que conta contra a cota.

Use user_id em vez de username para trabalhos de longa duração

@s mudam; o user_id numérico não. Se você agenda um trabalho para reextrair os seguidores das mesmas contas toda semana, resolva cada nome de usuário para um user_id uma vez e o armazene. Do contrário, um alvo se renomeando silenciosamente quebra o pipeline, e os seus logs dizem "user not found" sem causa óbvia.

def resolve_user_id(username):
    resp = requests.get(
        f"https://api.sorsa.io/v3/username-to-id/{username}",
        headers={"ApiKey": API_KEY},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["id"]

Os endpoints de conversão de ID cobrem o conjunto completo: nome de usuário para ID, ID para o nome de usuário atual e URL de perfil para ID. Armazene os IDs; resolva de volta para nomes de usuário apenas quando você precisar deles para exibição.

Paralelize entre contas, não dentro de uma

O cursor de paginação é sequencial por design: você não consegue buscar a página 7 sem primeiro buscar as páginas 1 a 6, já que cada resposta te entrega o cursor da próxima. Não há aceleração dentro da extração de uma única conta.

Entre contas é diferente. Para puxar seguidores de 20 concorrentes, rode essas 20 extrações concorrentemente contra o limite de 20 req/s. Com Python assíncrono:

import asyncio
import aiohttp

async def fetch_page(session, url, params):
    async with session.get(url, params=params, headers={"ApiKey": API_KEY}) as r:
        return await r.json()

async def extract_one(session, username):
    users = []
    cursor = None
    while True:
        params = {"username": username}
        if cursor:
            params["next_cursor"] = cursor
        data = await fetch_page(session, "https://api.sorsa.io/v3/followers", params)
        users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        if not cursor:
            return username, users
        await asyncio.sleep(0.05)

async def extract_many(usernames):
    async with aiohttp.ClientSession() as session:
        tasks = [extract_one(session, u) for u in usernames]
        return dict(await asyncio.gather(*tasks))

results = asyncio.run(extract_many(["stripe", "vercel", "supabase", "render"]))

Limite a concorrência ao seu rate limit dividido pela latência por requisição. A 20 req/s e cerca de 150 ms por requisição, três a quatro extrações concorrentes saturam o teto.

Trabalhando com os dados de resposta

Cada objeto de usuário carrega o perfil completo, então a maior parte do processamento downstream não precisa de chamadas extras de API. Algumas coisas que vale saber sobre o formato:

• O campo id é uma string, não um inteiro, mesmo parecendo numérico. IDs de usuário do Twitter excedem a faixa de inteiro com sinal de 64 bits que algumas linguagens tratam nativamente, então a API os serializa como strings. Não converta para int a menos que a sua ferramenta lide com valores de 64 bits com segurança.
• O campo created_at é ISO 8601 (por exemplo 2009-06-02T20:12:29Z), então parseia direto: datetime.fromisoformat(created_at.replace("Z", "+00:00")). Nenhuma string de formato customizada é necessária.
• A description (bio) pode conter quebras de linha, emoji e unicode de todo tipo. Sanitize-a antes de escrever em CSV ou em qualquer pipeline que não lide com UTF-8 de forma limpa.
• O campo location é uma string livre digitada pelo usuário, não um campo geo validado. Para dados de país confiáveis, o fluxo de geografia de audiência usa o endpoint /about para puxar a tag de país que o X anexa a cada conta, e o guia de analisar seguidores por país percorre o detalhamento completo.

Para uma análise mais profunda da audiência, nossa comparação de métodos para extrair seguidores do Twitter percorre a filtragem por palavra-chave de bio para qualificação de leads e a busca por contas que seguem vários concorrentes. Para transformar uma lista bruta em uma planilha pronta para CRM, veja exportar dados do X para o Google Sheets; para pontuar a mesma lista quanto a contas falsas ou inativas, o guia de auditoria de seguidores falsos cobre isso. Este artigo permanece na mecânica da API.

Por que /verified-followers existe como um endpoint separado {#why-verified-followers-exists-as-a-separate-endpoint}

Filtrar seguidores por verificação no lado do cliente é trivial (u.get("verified") is True), então um endpoint dedicado /verified-followers conquista seu lugar por duas razões práticas. Primeiro, em contas com milhões de seguidores onde usuários verificados são uma pequena minoria, percorrer a lista inteira para extraí-los desperdiça requisições e tempo de relógio; o endpoint retorna apenas o subconjunto verificado, ordenado da mesma forma que /followers. Segundo, o filtro de "audiência de alto perfil" é comum o suficiente em PR, jornalismo, pesquisa de investidores e marketing de influência para valer uma chamada.

curl "https://api.sorsa.io/v3/verified-followers?username=stripe" \
  -H "ApiKey: YOUR_API_KEY"

A resposta e o comportamento de paginação são idênticos aos de /followers. Veja a referência da API de seguidores verificados para o schema completo.

Casos de borda que vão te pegar {#edge-cases-that-will-trip-you-up}

Mesmo em uma API limpa, os dados de seguidores têm algumas peculiaridades que vale conhecer antes de você colocar um pipeline no ar. As quatro abaixo respondem pela maioria das surpresas que as equipes encontram em produção.

Contas protegidas retornam um erro. Se o alvo definiu os tweets como privados (a flag protected é true), as listas de seguidores e de seguindo dele não são acessíveis a ninguém fora dos seguidores aprovados, e o endpoint retorna um erro em vez de um resultado parcial. Cheque a flag protected do perfil com o endpoint /info antes da extração se você está fazendo script entre muitas contas.

O contador de seguidores e a lista extraível não vão bater exatamente. O followers_count de um perfil é um contador em tempo real que o X mantém. A lista que você percorre pela API pode voltar levemente menor por causa de contas suspensas, usuários desativados e contas que recentemente deixaram de seguir mas ainda não saíram do contador. Espere alguns por cento de desvio em contas grandes, e não escreva checagens de igualdade estrita contra followers_count.

Os dados de perfil são atuais, não históricos. Cada objeto de usuário reflete o perfil como ele existe agora, não seu estado quando o follow aconteceu. Se alguém seguiu a Stripe em 2019 e desde então se renomeou, o username na sua extração é o novo @. O id numérico é estável; o @ não.

A ordenação é aproximadamente cronológica reversa. Tanto /followers quanto /follows retornam resultados na ordem em que o X os fornece, geralmente os follows mais novos primeiro, então as primeiras páginas trazem os seguidores adquiridos mais recentemente. O X não se comprometeu oficialmente com essa ordenação, então não construa lógica que dependa dela permanecer fixa para sempre, embora ela tenha se mantido consistente na prática.

Quando a API oficial do X ainda faz sentido {#when-the-official-x-api-still-makes-sense}

A API oficial do X é a escolha certa em dois casos específicos: ler os dados da sua própria conta, e qualquer fluxo que tenha de escrever. Ler os seus próprios seguidores ficou barato em 20 de abril de 2026 na tarifa de leitura própria de US$ 0,001, então para painéis pessoais e ferramentas de gestão de conta o GET /2/users/:id/followers oficial com autenticação de contexto de usuário via OAuth é um encaixe razoável. Ações de escrita (postar, curtir, seguir) são exclusivas da API oficial e não algo que provedores focados em leitura tratam.

Para qualquer conta de terceiro, que é o caso realista para quase toda aplicação comercial, o cálculo muda. O custo por recurso sobe cerca de dez vezes em comparação com as leituras próprias, o OAuth 2.0 adiciona atrito ao fluxo de autenticação, e os rate limits são impostos em janelas de 15 minutos que retornam um 429 quando excedidas e que pagar mais não afrouxa. Para equipes saindo da API oficial após as mudanças de preço, a documentação de migração da Sorsa cobre o mapeamento endpoint por endpoint.

A árvore de decisão é curta:

1. Lendo apenas os dados da sua própria conta? A API oficial do X serve. Barata, e os dados são canônicos.
2. Lendo os dados de qualquer outra conta? Uma API alternativa do Twitter (X) é o melhor encaixe. A diferença de custo é grande o suficiente para não precisar de um olhar mais de perto.
3. Precisa postar, curtir ou seguir? Só a API oficial do X. Ações de escrita estão fora do escopo de um provedor somente leitura como a Sorsa.

Na prática

Reconstruímos um trabalho de extração de seguidores para um fundo quantitativo que rastreava sentimento em contas fintech do X. Eles precisavam das listas de seguidores de cerca de 50 contas concorrentes de médio porte, com média de 80.000 seguidores cada, cerca de quatro milhões de objetos de usuário no total. Na tarifa de leitura não-própria da API oficial, essa extração única saía perto de US$ 40.000. O mesmo trabalho em uma API de terceiro de tarifa fixa deu cerca de US$ 40 de cota e rodou em uma tarde, com um formato de dados idêntico. O motor é estrutural, e não um desconto: a API oficial cobra cada objeto de usuário que retorna, enquanto uma API por requisição cobra a chamada e retorna 200 perfis dentro dela. Para audiências na casa dos milhões, amostrar os primeiros 10.000 a 20.000 seguidores (50 a 100 requisições) costuma ser representativo da audiência recente e evita pagar para percorrer a cauda inteira.

Perguntas frequentes {#faq}

O que é a API de seguidores do Twitter?

A API de seguidores do Twitter é o conjunto de endpoints que recupera programaticamente as contas que seguem um usuário do Twitter (X), e, na mesma família de endpoints, as contas que esse usuário segue. A versão oficial é GET /2/users/:id/followers e GET /2/users/:id/following. Provedores de terceiros como a Sorsa expõem os mesmos dados por uma única chave de API e cobrança por requisição em vez de OAuth e cobrança por recurso.

Como obter uma lista de seguindo do Twitter via API?

Para obter uma lista de seguindo (as contas que um usuário segue, não as contas que o seguem), chame o endpoint "following" em vez do de seguidores. Na API oficial é GET /2/users/:id/following; na Sorsa é GET /v3/follows, com os mesmos parâmetros e paginação de 200 por página que o endpoint de seguidores. Listas de seguindo costumam ser menores do que listas de seguidores e muitas vezes mais reveladoras, já que mostram quem uma conta escolhe acompanhar.

Quanto custa a API oficial do X para dados de seguidores em 2026?

Após a atualização de 20 de abril de 2026, o X cobra US$ 0,001 por recurso para "Owned Reads" (seus próprios dados) e a tarifa padrão de leitura não-própria, US$ 0,010 por recurso, para os dados de qualquer outra conta. A conta é calculada por objeto de usuário retornado, não por requisição. Uma lista de seguidores de 100.000 contas em uma leitura não-própria é cerca de US$ 1.000.

Qual é a diferença entre cobrança por recurso e por requisição?

A cobrança por recurso conta cada objeto de usuário em uma resposta como uma cobrança separada, então uma requisição da API oficial que retorna 1.000 seguidores custa o mesmo que 1.000 consultas individuais. A cobrança por requisição, que a Sorsa usa, conta a requisição inteira como uma unidade contra a sua cota mensal independentemente de quantos usuários voltem. Para listas de seguidores, onde cada chamada retorna até 200 usuários, essa é a diferença entre pagar por 200 coisas ou por uma.

Você deveria usar user_id ou username nas chamadas de API?

Use username para consultas ad-hoc e exploração. Use user_id para qualquer código que rode mais de uma vez. @s mudam quando as contas se renomeiam; o ID numérico é estável pela vida da conta. Para trabalhos agendados, resolva o nome de usuário para um user_id uma vez com o endpoint username-to-id, armazene-o e passe user_id daí em diante.

Como tratar a resposta de rate limit 429?

Durma um segundo e tente de novo. O limite de 20 req/s da Sorsa não tem penalidade por atingi-lo: você recebe um 429, espera, e a próxima requisição funciona. Não há token buckets, nem janelas de 15 minutos, nem sub-limites por endpoint. Um wrapper leve de retry que captura respostas 429 e 5xx com backoff curto basta para produção.

Por que o contador extraído não bate com o followers_count do perfil?

O valor followers_count é um contador em tempo real que o X mantém, então a lista extraível pode voltar levemente menor. Contas suspensas, usuários desativados e pessoas que recentemente deixaram de seguir mas não saíram do contador todos criam desvio. Espere alguns por cento de diferença em contas grandes. Isto é comportamento da plataforma, não um bug no seu código, então evite checagens de igualdade estrita.

Quão frescos são os dados de seguidores?

Os objetos de usuário refletem o perfil como ele existe no momento da requisição, então contadores, bios, imagens de perfil e status de verificado são atuais. As relações de follow são tipicamente refletidas em segundos a minutos após acontecerem no X. Para algo mais próximo de streaming, os padrões de monitoramento em tempo real cobrem como detectar novos seguidores e menções em um intervalo apertado.

Primeiros passos {#getting-started}

Para experimentar isto contra a sua própria conta ou qualquer conta pública:

1. Cadastre-se para uma chave de API no painel de visão geral. Toda chave nova inclui 100 requisições grátis: única vez, sem cartão, que nunca expiram e são válidas em todos os 40 endpoints. Nos endpoints de seguidores, isso é até 20.000 perfis antes de você pagar qualquer coisa.
2. Rode o exemplo em cURL ou Python acima com o seu @ como o parâmetro username.
3. Para uma prévia no-code, abra o Playground da API e chame /followers diretamente no navegador.
4. Dados de seguidores na Sorsa saem a partir de US$ 0,01 por 1.000 perfis, já que uma requisição retorna até 200 perfis completos a uma tarifa fixa por requisição. Planeje para volume na página de preços: a partir de US$ 0,02 por 1.000 perfis no Starter e a partir de US$ 0,01 por 1.000 perfis no Pro e no Enterprise, com todo plano rodando ao fixo de 20 requisições por segundo.

O código completo, a referência de endpoints e os padrões de paginação vivem na documentação de seguidores e seguindo. Para extração não via API (extensões de navegador, scrapers caseiros, exportações manuais de dados do X), veja a comparação de métodos linkada no topo deste guia. Para como o mercado de API de dados do Twitter de terceiros se compara à API oficial do X em geral em 2026, veja nosso detalhamento de alternativas à API do Twitter.

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

Como este guia foi montado: os endpoints, o código e os padrões vêm do nosso próprio trabalho construindo e operando a API do Twitter (X) da Sorsa e rodando extração de seguidores contra contas públicas ao vivo. Os custos e o modelo da API oficial foram verificados contra o preço de desenvolvedor publicado do X e o comportamento de rate limit documentado nos recursos de desenvolvedor do X. Verificado pela última vez em julho de 2026.