Conversor de ID do Twitter: nome de usuário, ID e link de perfil

Por Sorsa Editorial

Atualizado em julho de 2026: adicionamos a opção inicial de 100 requisições grátis (sem cartão), reformulamos o preço de conversão para tarifas fixas por 1.000 conversões e reverificamos as tarifas oficiais de leitura por pagamento por uso.

Em resumo: Um ID de usuário do Twitter (X) é um número permanente de 64 bits atribuído na criação da conta, enquanto o @nomedeusuario pode mudar a qualquer momento. Para converter entre eles, envie o @, o ID numérico ou a URL de perfil a um endpoint de consulta. Armazene o ID, não o @, já que o ID sobrevive a renomeações.

Se você já armazenou @nome_da_marca como chave primária e depois viu aquela conta se rebrandizar para @nova_marca, você já sabe por que isso importa. O X deixa os usuários mudarem um @ quando quiserem, e uma vez que @nome_da_marca é liberado, qualquer um pode reivindicá-lo. O ID numérico de usuário é o único identificador que permanece atrelado à conta original por toda a vida.

Para fazer essas conversões em código, a Sorsa API, um provedor alternativo de API do Twitter (X), expõe três endpoints dedicados (@ para ID, ID para @, URL de perfil para ID) atrás de uma única chave de API, sem fluxo OAuth e sem fila de aprovação de app. Cada conversão conta como uma requisição fixa em vez da medição por recurso que a API oficial usa, então resolver 100.000 @s sai a partir de US$ 199 no plano Pro contra cerca de US$ 1.000 em créditos da API oficial do X. Toda chave nova começa com 100 requisições grátis (única vez, sem cartão, que nunca expiram, todos os 40 endpoints), o bastante para converter um primeiro lote de contas antes de decidir por um plano. Para consultas avulsas em que você não quer escrever código, o playground gratuito de Conversor de ID faz as três conversões no navegador sem chave nenhuma.

Divulgação: A Sorsa API é o nosso produto. As comparações de preço abaixo usam as tarifas de pagamento por uso publicadas da API oficial do X, verificadas em julho de 2026. Confira as tarifas atuais contra a sua própria carga antes de se comprometer.

Este guia é o caminho do desenvolvedor pelo tema: quando você de fato precisa converter, por que o design desses identificadores importa, como fazer cada conversão em código e como rodá-la em milhares de contas sem o seu pipeline quebrar.

Índice

• Por que IDs de usuário são o único identificador em que você pode confiar
• Como os IDs de usuário do Twitter são gerados
• Como encontrar um ID de usuário do Twitter
• As três operações de conversão
• Quanto custa a conversão de ID em 2026?
• Convertendo com a Sorsa API
• Conversão em lote em escala
• Normalizando entrada mista
• Detectando mudanças de @
• Na prática
• Primeiros passos
• Perguntas frequentes

Por que IDs de usuário são o único identificador em que você pode confiar {#why-user-ids-are-the-only-identifier-you-can-trust}

Um nome de usuário no X é mutável. Um usuário pode mudar @nome_antigo para @nome_novo hoje, e amanhã outra pessoa pode pegar @nome_antigo. Se uma aplicação trata o @ como chave primária, duas coisas quebram de uma vez: cada referência armazenada aponta para a conta errada, e um terceiro pode agora deter o @ que você usava para associar ao usuário original.

Isto não é um caso de borda raro. Um estudo longitudinal que monitorou 8,7 milhões de contas descobriu que cerca de 10% dos usuários do Twitter mudam o @ ao longo do tempo (Jain e Kumaraguru, IIIT-Delhi). No nosso próprio trabalho ajudando empresas a saírem da API oficial do X após a reformulação de preço de 2023, a rotatividade de @ foi um dos problemas de corrupção silenciosa de dados mais comuns que encontramos. Vários clientes rodavam painéis de monitoramento que armazenavam @s como chaves estrangeiras, e quando um concorrente rastreado se rebrandizava, o painel seguia coletando alegremente tweets de uma conta completamente não relacionada que havia pegado o @ antigo.

O ID de usuário é um inteiro de 64 bits atribuído na criação da conta. Ele não pode ser mudado, não pode ser transferido, é único em toda a plataforma e é a chave de junção sobre a qual todo pipeline confiável de dados do X é construído:

• Mudanças de @ não quebram o seu sistema. Quer uma conta se renomeie uma vez ou cinquenta vezes, o ID aponta para o mesmo perfil.
• Índices são mais rápidos. Indexação por inteiro é mais eficiente em armazenamento do que strings de comprimento variável, e consultas por chave primária numérica batem consultas por nome de usuário em qualquer escala.
• Junções entre períodos permanecem limpas. Ao casar contas entre conjuntos de dados coletados em momentos diferentes, IDs são a única chave segura. Um casamento de @ ao longo de anos pode silenciosamente casar duas pessoas diferentes.
• Vários endpoints exigem IDs. O /info-batch da Sorsa aceita user_ids, os endpoints de lista e de comunidade referenciam contas por ID numérico, e a maioria dos endpoints da API oficial do X igualmente espera IDs numéricos.

Se você tira uma coisa deste artigo: armazene IDs no seu banco de dados, não @s. Trate o @ como dado de exibição em cache que pode ficar obsoleto.

Armazene o ID como string, não como inteiro

Armazene e transporte IDs de usuário do Twitter como strings, mesmo que pareçam números. Os IDs Snowflake modernos de 19 dígitos excedem o limite de inteiro seguro do JavaScript (Number.MAX_SAFE_INTEGER, que é 2^53 - 1, ou 9.007.199.254.740.991), então parsear um ID em um número JS nativo silenciosamente arredonda os últimos dígitos e o corrompe. O mesmo risco aparece em qualquer lugar onde um valor de 64 bits caia em um tipo de 32 bits ou float. Mantenha os IDs em colunas de string ou em um BIGINT de 64 bits, nunca em um int padrão ou um number de JavaScript. A Sorsa API retorna cada ID como uma string JSON exatamente por esse motivo.

Como os IDs de usuário do Twitter são gerados {#how-twitter-user-ids-are-generated}

O Twitter construiu seu sistema de geração de ID, o Snowflake, em 2010 para resolver um problema de sistemas distribuídos. Na escala do Twitter, perguntar a um banco de dados central "qual é o próximo ID?" para cada novo tweet, mensagem ou conta não funcionaria. O Snowflake deixa qualquer servidor cunhar inteiros de 64 bits globalmente únicos de forma independente, sem coordenação, combinando três valores:

• Timestamp (41 bits): milissegundos desde a época do Twitter (2010-11-04 01:42:54.657 UTC).
• ID de worker / máquina (10 bits): identifica o servidor que gerou o ID.
• Número de sequência (12 bits): incrementa dentro do mesmo milissegundo, suportando até 4.096 IDs por máquina por milissegundo.

Adicione um bit de sinal e você tem 64 bits no total. Como o timestamp fica nos bits mais significativos, os IDs Snowflake são aproximadamente ordenáveis por tempo, e é por isso que os IDs de tweet são ordenados por tempo quando você os compara.

O detalhe do ID de usuário que a maioria das páginas de conversor erra

Aqui vai um ponto que a maioria das páginas de conversor de ID afirma incorretamente: os IDs de tweet viraram Snowflake em 2010, mas o X não mudou os IDs de usuário para o formato Snowflake até fevereiro de 2016, e muitas páginas ainda repetem uma data errada (muitas vezes 2020). Segundo o próprio anúncio de migração de ID de 64 bits do X, os IDs Snowflake começaram a ser distribuídos a usuários, listas e buscas salvas em 1º de fevereiro de 2016. Antes disso, o X distribuiu IDs de usuário inteiros curtos e sequenciais por anos. É por isso que a conta do Jack Dorsey é 12, e por que contas criadas antes da mudança têm IDs curtos e baixos, enquanto contas criadas depois têm IDs Snowflake longos, de 18 a 19 dígitos.

A consequência prática: você pode extrair um timestamp de criação de qualquer ID de tweet, mas não pode extrair de forma confiável uma data de registro de um ID de usuário antigo, porque os IDs de usuário pré-2016 não carregam timestamp embutido. Se você precisa de uma data de entrada para uma conta mais antiga, leia o campo created_at do perfil diretamente, ou use o verificador de idade de conta para uma consulta avulsa rápida.

Como encontrar um ID de usuário do Twitter {#how-to-find-a-twitter-user-id}

O X não exibe um ID de usuário em nenhum lugar da sua interface, então você tem de derivá-lo. Há três caminhos práticos, em ordem aproximada de esforço:

A forma manual (lenta). Abra o perfil, veja o código-fonte da página (Ctrl+U ou Cmd+U) e busque no HTML por user_id ou rest_id. Ou abra as ferramentas de desenvolvedor do navegador (F12), observe a aba Network, atualize e leia o ID de uma resposta de API. Ambos funcionam para uma única conta, mas são tediosos, quebram sempre que o X reembaralha sua marcação e não escalam além de um punhado de consultas.

Um conversor gratuito (avulso). Cole um @, ID ou URL de perfil em uma ferramenta de consulta e leia o resultado. O playground de Conversor de ID da Sorsa lida com as três direções no navegador sem cadastro e sem chave de API, e também retorna o perfil para você confirmar que tem a conta certa. Contas suspensas, apagadas ou que nunca existiram retornam um resultado de não encontrado; contas protegidas (privadas) retornam o ID mas com estatísticas limitadas.

A API (em escala). Quando você precisa resolver mais do que algumas contas, ou rodar a consulta sem supervisão dentro de um pipeline, chame um endpoint de conversão diretamente. O código abaixo mostra as três operações em Python.

As três operações de conversão {#the-three-conversion-operations}

Há exatamente três operações de conversão que você um dia precisa:

Cada operação é uma única chamada de API. Nenhuma delas exige OAuth, URLs de callback ou aprovação de app quando você usa uma API de terceiros como a Sorsa. Uma chave de terceiro substitui inteiramente o fluxo oficial de conta de desenvolvedor, então não há aplicação para submeter e nada para esperar, o mesmo caminho coberto no nosso guia sobre usar a API do X sem uma conta de desenvolvedor. Os exemplos em Python e curl para as três estão na seção de código abaixo, e cada uma mapeia para um endpoint documentado: @ para ID, ID para @ e link de perfil para ID.

Não há operação equivalente para tweets. Um ID de tweet é visível diretamente na URL do tweet (x.com/user/status/1234567890), então você o parseia da string da URL em vez de chamar uma consulta.

Quando usar o endpoint /info em vez disso

Se você precisa tanto do ID de usuário quanto do perfil completo (nome de exibição, contador de seguidores, bio, URL do avatar), não chame /username-to-id e depois /info separadamente. Chame /info?username=... diretamente: ele retorna o perfil completo, incluindo o campo id, em uma única requisição. Dividir isso em duas chamadas é um dos erros de custo mais comuns que vemos em revisões de código. Em volumes maiores, /info-batch agrupa até 100 perfis em uma requisição, o que traz o custo de puxar IDs junto com perfis completos para a partir de US$ 0,01 por 1.000 perfis nos planos de preço em lote.

Quanto custa a conversão de ID em 2026? {#how-much-does-id-conversion-cost-in-2026}

O preço mudou significativamente este ano. Em fevereiro de 2026, o X moveu sua API para um modelo de crédito por pagamento por uso como padrão para novos desenvolvedores, substituindo os antigos níveis Basic e Pro. Uma consulta de @ para ID na API oficial do X é uma leitura de usuário, cobrada a cerca de US$ 0,010 por recurso retornado, o que dá cerca de US$ 10,00 por 1.000 conversões. Para uma consulta ocasional dentro de uma ferramenta interna, tudo bem. Para trabalhos em lote ou recorrentes o custo soma rápido: resolver 100.000 @s custa cerca de US$ 1.000 em créditos da API oficial.

Na Sorsa, cada um dos três endpoints de conversão conta como uma requisição fixa, então o custo cai para a partir de US$ 1,80 por 1.000 conversões, e toda chave nova começa com 100 requisições grátis (única vez, sem cartão, que nunca expiram, todos os 40 endpoints) para testar o fluxo primeiro:

Por conversão, o plano Pro dá cerca de 5x mais barato do que a API oficial, e a diferença aumenta se você fizer em lote: consultas de perfil por /info-batch agrupam até 100 contas em uma única requisição. Para o quadro completo de como o modelo oficial mudou este ano, veja nosso detalhamento de preços da API do Twitter e os motivos por trás de por que a API oficial é tão cara. Os detalhes de plano do nosso lado estão na página de preços.

Uma ressalva honesta do lado oficial: o nível de leitura mais barato dela, leituras próprias a US$ 0,001 por recurso, é genuinamente competitivo, mas só se aplica quando um app lê os dados da sua própria conta por um conjunto fixo de endpoints. Consultas de @ para ID de contas arbitrárias de terceiros são leituras não-próprias cobradas na tarifa padrão de leitura de usuário, então o modelo fixo por requisição continua à frente para o trabalho de conversão que este guia cobre.

Convertendo com a Sorsa API {#converting-with-the-sorsa-api}

A autenticação é um único cabeçalho: ApiKey: YOUR_API_KEY. Sem fluxo OAuth, sem escopos, sem callback. Cada uma das três operações mapeia para um endpoint documentado, e elas compartilham a mesma chave.

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}


def username_to_id(handle: str) -> str:
    """Resolve a handle (without @) to its permanent numeric user ID."""
    resp = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["id"]  # returned as a string, keep it that way


def id_to_username(user_id: str) -> str:
    """Resolve a numeric user ID to the account's current handle."""
    resp = requests.get(f"{BASE}/id-to-username/{user_id}", headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["handle"]


def link_to_id(profile_url: str) -> str:
    """Extract the numeric user ID from a full profile URL."""
    resp = requests.get(
        f"{BASE}/link-to-id",
        headers=HEADERS,
        params={"link": profile_url},
    )
    resp.raise_for_status()
    return resp.json()["id"]


# Examples
print(username_to_id("elonmusk"))                    # "44196397"
print(id_to_username("44196397"))                    # "elonmusk"
print(link_to_id("https://x.com/elonmusk"))          # "44196397"

Para um equivalente em curl da primeira chamada:

curl "https://api.sorsa.io/v3/username-to-id/elonmusk" \
  -H "ApiKey: YOUR_API_KEY"
# {"id": "44196397"}

Conversão em lote em escala {#batch-conversion-at-scale}

Quando você tem uma planilha de @s de concorrentes, uma exportação de CRM ou uma lista de contas para semear um pipeline de monitoramento, você precisa convertê-las todas para IDs em uma passada. O padrão abaixo adiciona lógica de retry, rate limiting leve (a Sorsa permite 20 requisições por segundo por chave em todo plano) e tratamento gracioso de contas suspensas ou apagadas. Para uma cobertura mais ampla de paginação, agrupamento em lote e tratamento de erro pelo resto da API em Python, veja o guia da API do Twitter em Python.

import requests
import time
from typing import Iterable

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}


def batch_username_to_id(handles: Iterable[str], pause: float = 0.05) -> dict[str, str | None]:
    """
    Resolve a list of handles to user IDs.

    Returns a dict mapping handle -> id (or None if the lookup failed).
    Soft rate limit: ~20 req/s, well under Sorsa's per-key cap.
    """
    results: dict[str, str | None] = {}

    for handle in handles:
        handle = handle.strip().lstrip("@")
        try:
            resp = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS, timeout=10)
            if resp.status_code == 200:
                results[handle] = resp.json()["id"]
            elif resp.status_code == 404:
                results[handle] = None  # Account does not exist or is suspended
            elif resp.status_code == 429:
                time.sleep(1)  # Back off and retry once
                retry = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS, timeout=10)
                results[handle] = retry.json()["id"] if retry.status_code == 200 else None
            else:
                results[handle] = None
        except requests.RequestException:
            results[handle] = None

        time.sleep(pause)

    return results


handles = ["NASA", "SpaceX", "Tesla", "OpenAI", "stripe"]
id_map = batch_username_to_id(handles)

for handle, uid in id_map.items():
    print(f"@{handle:<10} -> {uid or '(not found)'}")

A direção reversa funciona da mesma forma. Troque a URL por /id-to-username/{user_id} e leia o campo handle da resposta.

Normalizando entrada mista {#normalizing-mixed-input}

Uma situação comum: sua aplicação aceita referências de conta de usuários finais ou sistemas upstream em qualquer formato que a fonte por acaso produza. Algumas entradas são @s pelados, algumas têm prefixo @, algumas são URLs completas, algumas já são IDs numéricos. O normalizador abaixo colapsa todos os quatro formatos em um ID de usuário estável, e pula a chamada de API inteiramente quando a entrada já é um ID.

def normalize_to_id(value: str) -> str:
    """
    Accept any of:
      - "elonmusk"
      - "@elonmusk"
      - "https://x.com/elonmusk"
      - "https://twitter.com/elonmusk"
      - "44196397"
    Returns the numeric user ID as a string.
    """
    value = value.strip().lstrip("@")

    # Already a numeric ID, no API call needed
    if value.isdigit():
        return value

    # Profile URL
    if "x.com/" in value or "twitter.com/" in value:
        return link_to_id(value)

    # Bare username
    return username_to_id(value)


# All four return the same ID
for source in ["elonmusk", "@elonmusk", "https://x.com/elonmusk", "44196397"]:
    print(f"{source:<35} -> {normalize_to_id(source)}")

Use isto como o primeiro passo em qualquer pipeline de ingestão. Ele garante que a lógica downstream sempre trabalhe com o identificador estável, não importa quão bagunçada seja a entrada.

Detectando mudanças de @ {#detecting-handle-changes}

Se você armazenou tanto o ID de usuário quanto o @ no momento da coleta, você pode periodicamente re-resolver os IDs e detectar quais contas se renomearam. Este é o fluxo para atualizar um banco de dados que pode conter nomes de exibição obsoletos.

def detect_renames(records: list[dict]) -> list[dict]:
    """
    records: list of {"user_id": str, "stored_handle": str}
    Returns: list of {"user_id", "old_handle", "new_handle"} for renamed accounts.
    """
    changes = []
    for record in records:
        try:
            current = id_to_username(record["user_id"])
        except requests.HTTPError:
            continue  # Account deleted, suspended, or transient error

        if current and current.lower() != record["stored_handle"].lower():
            changes.append({
                "user_id": record["user_id"],
                "old_handle": record["stored_handle"],
                "new_handle": current,
            })
        time.sleep(0.05)

    return changes


db_records = [
    {"user_id": "44196397", "stored_handle": "elonmusk"},
    {"user_id": "1234567890", "stored_handle": "old_brand_name"},
]

for change in detect_renames(db_records):
    print(f"Renamed: @{change['old_handle']} -> @{change['new_handle']} (ID {change['user_id']})")

Para uma auditoria de renomeação mais rica, o endpoint /about retorna username_change_count e last_username_change_at. Isso te diz não só o @ atual, mas quantas vezes uma conta se renomeou e quando aconteceu a mudança mais recente.

Na prática {#in-practice}

Uma equipe de análise social de cerca de 12 pessoas chegou até nós depois que um concorrente que elas rastreavam se rebrandizou, e o painel delas ingeriu silenciosamente os tweets de um estranho por quase três semanas antes que alguém percebesse. A causa raiz foi a clássica: elas haviam armazenado @s como chaves. A correção foi estrutural, e não esperta. Resolver cada @ para o seu ID de usuário na ingestão, armazenar o ID como chave, manter o @ apenas para exibição e rodar um re-resolve agendado para pegar renomeações (o padrão detect_renames acima).

O lado do custo importou também. O volume mensal de resolução de @ delas vinha rodando perto de US$ 1.000 em créditos de leitura de usuário da API oficial do X. No plano Pro a US$ 199 fixo por 100.000 requisições, virou um item de linha previsível, cerca de uma redução de 5x nessa carga, com folga extra porque consultas de perfil em massa por /info-batch empacotam até 100 contas em uma requisição. A vitória de confiabilidade, sem mais corrupção silenciosa entre contas, foi a parte com que elas mais se importaram.

Primeiros passos {#getting-started}

Três formas de experimentar isto:

1. No-code, sem cadastro. Abra o playground de Conversor de ID e cole qualquer @, ID ou URL de perfil. Útil para consultas avulsas e para confirmar que uma conta existe antes de você escrever qualquer código.
2. Chave de API com 100 requisições grátis. Crie uma conta gratuita e toda chave começa com 100 requisições grátis (única vez, sem cartão, que nunca expiram, todos os 40 endpoints). Jogue a chave no cabeçalho ApiKey e os exemplos em Python acima rodam como estão. Os planos pagos começam a partir de US$ 0,0049 por conversão no Starter, caindo para US$ 0,00199 no Pro, e o fixo de 20 requisições por segundo se aplica em todo plano.
3. Já está na API oficial do X? O guia de migração mapeia cada endpoint oficial para o seu equivalente na Sorsa, e nossa visão geral de alternativas à API do Twitter cobre os tradeoffs.

Os três endpoints de conversão aqui fazem parte de uma API somente leitura de 40 endpoints cobrindo perfis, tweets, seguidores, busca e verificação.

Perguntas frequentes {#frequently-asked-questions}

O que é um ID de usuário do Twitter (X)?

Um ID de usuário do Twitter é um inteiro único de 64 bits atribuído a uma conta do X quando ela é criada. Ele é permanente: não pode ser mudado, transferido nem reatribuído. Ao contrário do nome de usuário (@), que pode ser editado a qualquer momento, o ID de usuário permanece atrelado à mesma conta pela vida daquela conta, e é por isso que os desenvolvedores o usam como a chave estável para qualquer referência de conta.

Como encontrar o seu próprio ID de usuário do Twitter?

A interface do X não exibe o seu ID de usuário em lugar nenhum. Para encontrá-lo, cole o seu @ ou URL de perfil em um conversor como o Conversor de ID da Sorsa, ou envie o seu @ a um endpoint de consulta. Você também pode baixar o seu arquivo de dados do X nas configurações da conta, que inclui o seu ID de usuário nos metadados da conta.

Um ID de usuário do Twitter pode mudar?

Não. Um ID de usuário do Twitter é atribuído na criação da conta e é permanente pela vida da conta. Renomear a conta, mudar o nome de exibição, trocar de endereço de e-mail ou ser suspenso e depois reintegrado não muda o ID de usuário. A única coisa que muda é o vínculo entre um @ e um ID, que se desloca quando o próprio @ é mudado e o @ antigo fica disponível para outra pessoa reivindicar.

Por que alguns IDs de usuário do Twitter são curtos e outros muito longos?

O X atribuiu IDs inteiros curtos e sequenciais às contas iniciais, e é por isso que a conta do Jack Dorsey é 12, e só mudou os IDs de usuário para o formato Snowflake de 64 bits em fevereiro de 2016. Contas criadas antes dessa mudança têm IDs curtos e baixos. Contas criadas depois têm IDs Snowflake longos, de cerca de 18 a 19 dígitos, que codificam um timestamp de criação nos bits superiores.

Dá para decodificar uma data de registro de um ID de usuário?

Para contas criadas após a mudança para Snowflake em fevereiro de 2016, sim: desloque o ID à direita em 22 bits, adicione a época do Twitter (1288834974657), e você obtém o timestamp de criação em milissegundos. Para contas mais antigas com IDs sequenciais pré-2016, não, porque esses IDs não carregam timestamp embutido. Nesse caso, busque o perfil e leia o campo created_at diretamente.

Existe um conversor de ID do Twitter gratuito que não exige uma chave de API?

Sim. O playground de Conversor de ID da Sorsa lida com as três operações (@ para ID, ID para @, URL de perfil para ID) no navegador sem chave de API e sem cadastro, e retorna o perfil para você confirmar a conta. Ele é feito para consultas avulsas. Para trabalhos em lote, pipelines recorrentes ou qualquer coisa que rode sem supervisão, uma chave de API é o melhor encaixe, e toda chave nova começa com 100 requisições grátis (única vez, sem cartão) para você testar um lote antes de pagar.

Como os desenvolvedores podem converter milhares de nomes de usuário em IDs em escala?

Para trabalho de alto volume, a Sorsa API expõe três endpoints de conversão (/username-to-id, /id-to-username, /link-to-id) a uma requisição fixa por conversão. No plano Pro a US$ 199/mês por 100.000 requisições, cada conversão é cerca de US$ 0,002, cerca de 5x mais barato do que a tarifa por recurso da API oficial. A vazão é limitada a 20 requisições por segundo por chave, alta o suficiente para que o seu próprio código costume ser o gargalo, não a API.

Qual é a diferença entre um ID de usuário e um ID de tweet?

Ambos são inteiros de 64 bits no estilo Snowflake, mas vivem em namespaces separados e identificam coisas diferentes. Um ID de usuário identifica uma conta; um ID de tweet (também chamado de ID de status) identifica um único post. Os IDs de tweet são visíveis diretamente na URL do tweet (x.com/user/status/{tweet_id}), então nenhuma consulta é necessária para eles. Os IDs de usuário não são expostos em nenhum lugar da interface do X, e é por isso que existem endpoints de conversão dedicados.

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

Como este guia foi montado: ele se apoia no nosso trabalho prático construindo e operando uma API alternativa do Twitter (X) e em testes diretos contra os nossos endpoints de conversão ao vivo, cruzados com a documentação da Sorsa API para o comportamento dos endpoints e o anúncio oficial de preço da API do X para as tarifas atuais de pagamento por uso. A estrutura do Snowflake vem do post de engenharia original do Twitter, a mudança de ID de usuário de fevereiro de 2016 do anúncio de migração de ID de 64 bits do X, e o número de rotatividade de nome de usuário do estudo longitudinal de Jain e Kumaraguru. Números de preço e de tarifa verificados em julho de 2026. Mais sobre quem somos está na nossa página Sobre.