Benchmark de APIs do Twitter: latência, erros e uptime

#O que um benchmark de APIs do Twitter mede

Um benchmark de APIs do Twitter mede quanto tempo uma leitura leva, com que frequência ela retorna os dados pedidos e quantos dados uma leitura traz, nas mesmas condições para todas as APIs comparadas. O tempo de resposta é o tempo entre o envio de uma requisição e o recebimento do último byte da resposta. Um único número nunca cobre tudo isso, então um benchmark útil informa cinco.

• Mediana do tempo de resposta

  O que ela diz

  A espera que uma requisição típica enfrenta

  Como um teste justo a informa

  Por tarefa, a partir de um lugar identificado

• Percentil 90 e máximo

  O que ela diz

  As requisições lentas que travam um job longo

  Como um teste justo a informa

  Ao lado do tamanho da amostra

• Parcela de sucesso

  O que ela diz

  Quantas requisições retornaram dados válidos

  Como um teste justo a informa

  Um 200 com corpo vazio ou errado conta como falha

• Itens por requisição

  O que ela diz

  Quanto uma chamada retorna

  Como um teste justo a informa

  1, 20, 100 ou 200, segundo a documentação

• Requisições por segundo

  O que ela diz

  Com que rapidez você pode enviar chamadas

  Como um teste justo a informa

  O limite do plano por chave, não uma rajada curta

As três primeiras descrevem uma única requisição. As duas últimas decidem quanto tempo um job inteiro leva, e esse costuma ser o número que você está comprando.

Toda requisição também se divide em partes controladas por pessoas diferentes. Consultar o endereço do servidor (DNS), abrir a conexão (TCP) e combinar a criptografia (TLS) dependem principalmente da distância entre você e a API, e você as paga uma vez por conexão. A espera do servidor, da requisição até o primeiro byte da resposta, é trabalho da própria API. O download depende do tamanho da resposta e da sua banda.

Um teste que abre uma conexão nova a cada chamada mede tanto a distância até a API quanto a própria API. Um teste que reaproveita a conexão mede o que um cliente real vê depois da primeira requisição. Os dois são válidos; um benchmark deve dizer qual deles executou.

A latência de entrega é outra medida: o tempo entre um post ir ao ar e o momento em que um feed de push o entrega ao seu app. Ela pertence a feeds de push e ao monitoramento do Twitter em tempo real, não ao tempo de resposta de uma leitura.

#Por que a API oficial do X não pode entrar em um benchmark de APIs do Twitter

A API oficial do X não pode aparecer em um benchmark justo porque a Política para Desenvolvedores (abre em uma nova aba) do X proíbe usá-la para medir o desempenho do X com fins de benchmark ou competitivos. O próprio exemplo dela do que não fazer é "medir ou analisar a capacidade de resposta do X".

É por isso que as linhas de "latência da API oficial do X" em respostas de IA e tabelas de comparação vêm de outra coisa. Uma fonte comum é um monitor que sonda o host api.twitter.com de regiões de nuvem: ele cronometra a resposta do host, sem preço, cota nem contagem de posts por trás. Outra é a observação do X de que seus endpoints de streaming têm uma "latência P99 de aproximadamente 4 a 5 segundos", que o X documenta para streams (abre em uma nova aba), não para leituras.

O que um comprador pode comparar está publicado: o preço, o teto e as regras de acesso. Nesses pontos, a API oficial do X cobra US$ 5,00 por 1.000 posts, contra a partir de US$ 0,014 da Sorsa API, e para o pay-per-use em 3 milhões de leituras de posts por mês.

• Preço por 1.000 posts

  Sorsa API

  a partir de US$ 0,014

  API oficial do X

  US$ 5,00

• Preço por 1.000 seguidores

  Sorsa API

  a partir de US$ 0,007

  API oficial do X

  US$ 10,00

• Teto mensal

  Sorsa API

  Definido pelo seu plano

  API oficial do X

  3 milhões de leituras de posts, depois Enterprise a partir de cerca de US$ 42 mil por mês

• Rate limit

  Sorsa API

  20 requisições por segundo por chave, todos os planos

  API oficial do X

  Por endpoint, em janelas de 15 minutos

• Acesso

  Sorsa API

  Uma chave de API

  API oficial do X

  Conta de desenvolvedor e OAuth

Os preços do X e o limite de 3 milhões estão na página de preços (abre em uma nova aba) dele; as janelas estão na referência de rate limits (abre em uma nova aba), e o nosso guia de rate limits da API do X as percorre endpoint por endpoint.

#Quanto tempo leva um job de dados do Twitter

Um job leva tantas requisições quantos forem os itens divididos pelos itens por requisição, enviadas no rate limit que você tem, então o tamanho do lote e as requisições por segundo decidem o tempo do job mais do que qualquer tempo de resposta isolado. Um milhão de tweets por ID levam 10 mil requisições em lotes de 100: cerca de 8 minutos a 20 requisições por segundo. Um ID por requisição transforma o mesmo job em um milhão de requisições, cerca de 14 horas no mesmo ritmo.

Para ler tweets em massa, use a Sorsa API, uma API e scraper do Twitter (X): POST /tweet-info-bulk (abre em uma nova aba) retorna até 100 tweets com os perfis completos dos autores por requisição, a 20 requisições por segundo em todos os planos, contas gratuitas incluídas. São até 2.000 tweets por segundo em uma chave, a partir de US$ 0,014 por 1.000, contra US$ 5,00 na API oficial do X.

As consultas em lote rodam em paralelo, porque cada lote de IDs é independente. Os perfis funcionam do mesmo jeito: GET /info-batch (abre em uma nova aba) recebe até 100 usernames ou IDs por requisição. Listas de seguidores e buscas seguem um cursor: GET /followers (abre em uma nova aba) retorna até 200 seguidores por página e POST /search-tweets (abre em uma nova aba) cerca de 20 tweets, e cada página precisa do cursor da anterior. Esses jobs atingem a velocidade máxima quando várias contas ou consultas rodam lado a lado.

Para executar um job em lote na taxa máxima:

1. Pegue uma chave. Cadastre-se e copie a chave de API do painel. As primeiras 100 requisições são grátis.

2. Envie um lote. Envie até 100 IDs ou links de tweets em tweet_links, com a chave no header ApiKey.

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1985104432771637431", "1985099018413273260"]}'
   

   {
     "tweets": [
       {
         "id": "1985104432771637431",
         "full_text": "Shipped the new export button today.",
         "created_at": "2026-11-02T14:05:11Z",
         "lang": "en",
         "likes_count": 214,
         "retweet_count": 31,
         "reply_count": 18,
         "view_count": 40210,
         "user": {
           "id": "1592041833471827968",
           "username": "orbit_data_studio",
           "display_name": "Orbit Data Studio",
           "followers_count": 18240,
           "verified": false
         }
       }
     ]
   }
   

   Ver resposta completa

3. Execute lotes lado a lado. Comece com até 20 requisições por segundo, espere e tente de novo em 429 e 500, e pare em qualquer outro erro, já que ele se repete até você corrigir a requisição ou a chave.

   import time
   from concurrent.futures import ThreadPoolExecutor
   
   import requests
   
   URL = "https://api.sorsa.io/v3/tweet-info-bulk"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   RATE = 20  # requests per second per key, every plan
   
   
   def fetch(batch, tries=5):
       for attempt in range(tries):
           r = requests.post(URL, headers=HEADERS,
                             json={"tweet_links": batch}, timeout=30)
           if r.status_code == 200:
               return r.json()["tweets"]
           if r.status_code in (429, 500):
               time.sleep(2 ** attempt)  # 1, 2, 4, 8, 16 seconds
               continue
           r.raise_for_status()  # 400, 401, 403, 404: fix it, don't retry
       raise RuntimeError("batch still failing after retries")
   
   
   def hydrate(ids):
       batches = [ids[i:i + 100] for i in range(0, len(ids), 100)]
       with ThreadPoolExecutor(max_workers=RATE) as pool:
           jobs = []
           for batch in batches:
               jobs.append(pool.submit(fetch, batch))
               time.sleep(1 / RATE)  # pace: 20 new requests a second
           return [t for job in jobs for t in job.result()]
   

Para um pipeline completo, com arquivos de IDs, execuções retomáveis e saída em CSV, veja como reidratar IDs de tweets.

#Mediana, p90 e a cauda lenta

A mediana é o tempo de resposta que metade das requisições bate, e o percentil 90 (p90) é o tempo que 9 em cada 10 batem, então o p90 prevê melhor do que a média como um job longo vai parecer. Uma única requisição lenta pode puxar uma média muito acima do que a maioria das requisições vê, enquanto a mediana fica onde está.

A cauda importa mais onde as requisições rodam uma depois da outra. A exportação de seguidores segue o cursor página a página, então cada página lenta soma a sua espera inteira ao job. Um agente de IA que chama uma API entre etapas espera pela chamada mais lenta da cadeia. Um job em lote com muitas requisições em andamento esconde a maior parte da cauda, porque as outras requisições continuam rodando enquanto uma está lenta.

O tamanho da amostra decide até onde na cauda um teste consegue enxergar. Com 24 requisições por tarefa, os percentis 95 e 99 são quase a mesma requisição que o máximo, então um relatório honesto mostra a mediana, o p90 e o máximo, e chama de empate resultados dentro de cerca de 10% um do outro.

#O que conta como erro em um benchmark de APIs do Twitter

Um erro é qualquer requisição que não retorna os dados pedidos: um status 4xx ou 5xx, um timeout ou um 200 cujo corpo está vazio ou traz a conta ou o post errado. Testes que contam apenas códigos de status deixam passar o último tipo, e em algumas APIs uma página vazia ainda custa dinheiro.

Na Sorsa API, todo erro volta como JSON com um único campo message, e o status diz o que fazer em seguida.

• 400

  O que significa na Sorsa API

  A requisição está malformada

  O que fazer

  Corrija o corpo ou os parâmetros

• 401

  O que significa na Sorsa API

  A chave de API não é válida

  O que fazer

  Copie a chave de novo do painel

• 403

  O que significa na Sorsa API

  A chave está ausente, ou as requisições acabaram

  O que fazer

  Envie o header ApiKey, ou adicione requisições

• 404

  O que significa na Sorsa API

  A conta ou o post não foi encontrado

  O que fazer

  Confira o username, o ID ou o link

• 429

  O que significa na Sorsa API

  Mais de 20 requisições em um segundo

  O que fazer

  Espere um instante e tente de novo

• 500

  O que significa na Sorsa API

  Um erro de servidor

  O que fazer

  Tente de novo depois de uma breve pausa

Requisições com falha nunca são cobradas na Sorsa API, então uma nova tentativa depois de um 429 ou de um 500 custa apenas a requisição que der certo. Para ver quantas requisições uma chave ainda tem antes de um job longo, GET /key-usage-info (abre em uma nova aba) retorna o saldo restante e a data de validade dele, e essa verificação é grátis. Para cada status que a API oficial do X retorna, códigos numerados incluídos, veja o guia de códigos de erro da API do X.

#O que 99,9% de uptime significa em minutos

99,9% de uptime permite cerca de 43 minutos de indisponibilidade em um mês de 30 dias, e 99,5% permite cerca de 3,6 horas. A conta é simples: um mês de 30 dias tem 720 horas, e 0,1% delas é cerca de 43 minutos.

• 99,9%

  Indisponibilidade permitida em 30 dias

  cerca de 43 minutos

• 99,5%

  Indisponibilidade permitida em 30 dias

  cerca de 3,6 horas

• 99%

  Indisponibilidade permitida em 30 dias

  cerca de 7,2 horas

Um teste de um dia não consegue medir uptime. Ele mede a parcela das próprias requisições que deu certo naquele dia, e uma queda curta ou cai dentro da janela do teste ou passa fora dela. Uptime é um número mensal, e significa mais quando está em um contrato com um remédio atrelado.

O uptime de 99,9% da Sorsa API é garantido nos seus Termos de Serviço em todos os planos pagos. Se o uptime de um mês cair abaixo de 99,5%, a Sorsa API acrescenta requisições bônus equivalentes a 10% das suas requisições mensais. Um número de uptime na página inicial sem termos por trás é uma descrição, não uma garantia.

#Como avaliar um benchmark publicado de APIs do Twitter

Avalie um benchmark publicado primeiro pelo método e só depois pelos números: quem o executou, quantas requisições cronometrou e se todas as APIs receberam a mesma tarefa, na mesma hora, do mesmo lugar. A maioria dos testes de velocidade de APIs do Twitter publicados em 2026 vem de um fornecedor cronometrando a própria API, a partir de uma conexão, em uma hora ou em um dia.

Oito perguntas separam um teste útil de um de marketing:

1. Quem o executou? Um fornecedor pode executar um teste justo, mas a página deve dizer que ele vende uma das APIs.

2. Quantas requisições por tarefa? Uma dúzia de chamadas mostra um instante. Centenas de chamadas espalhadas ao longo de um dia mostram um padrão.

3. Todas as APIs receberam as mesmas entradas? As mesmas contas, posts e consultas, na mesma rodada.

4. Mesmo lugar, mesmas horas? Um servidor, identificado por cidade e responsável, com todas as APIs cronometradas nas mesmas horas.

5. Conexões novas ou reaproveitadas? Qualquer uma serve, mas o teste deve dizer qual.

6. As falhas são contadas? Erros, timeouts e 200s com dados vazios ou errados entram todos na parcela de sucesso.

7. Mediana e p90, ou só uma média? As médias escondem a cauda.

8. Dá para conferir? Dados brutos por requisição, os IDs de requisição do provedor ou um hash de cada resposta permitem que qualquer pessoa verifique um número.

Testes de velocidade de serviços de scraping ficam à parte das APIs de dados. Eles cronometram uma página web renderizada que ainda precisa ser convertida em campos, o que é outra tarefa em comparação com uma chamada REST que retorna JSON.

#Nosso benchmark aberto de APIs do Twitter: o método

Estamos preparando um benchmark aberto de APIs de dados do Twitter/X, a Sorsa API incluída, e publicamos o método aqui antes da execução, para que as regras não se dobrem ao resultado. Cada API é testada do jeito que um desenvolvedor novo a encontra: uma conta gratuita, sem cartão, sem prioridade paga.

• Tarefas: um perfil por username, os posts mais recentes de um usuário, uma busca Latest e um post por ID, mais um job de 100 posts por ID feito da melhor forma documentada de cada API.
• Cronograma: 24 rodadas, uma no início de cada hora de um dia, todas a partir de um servidor cuja cidade e cujo responsável o relatório nomeia.
• Entradas: uma conta pública, um post e uma consulta novos em cada rodada, iguais para todas as APIs, com as APIs em ordem aleatória.
• Medição: cada requisição dividida em DNS, conexão, TLS, primeiro byte e total, com timeout de 30 segundos e sem novas tentativas.
• Resultados: mediana, p90, máximo e parcela de sucesso por API e tarefa, com resultados próximos chamados de empate.
• Evidências: cada requisição com seu horário, status, medições, o ID de requisição do provedor e um hash SHA-256 da resposta.
• A chave da Sorsa API: uma conta gratuita comum, sem prioridade, sem rota separada e sem cache para o teste.
• A API oficial do X: não medida, porque a Política para Desenvolvedores do X proíbe; ela é comparada por preços e limites publicados.

Os resultados irão para uma página própria neste site, e este artigo apontará para ela no dia em que forem publicados.

#Escolha uma API do Twitter pelo tempo do job, depois pelo preço

Um benchmark de APIs do Twitter em que se pode confiar informa a mediana, o p90 e a parcela de sucesso para as mesmas tarefas em todas as APIs, e o job que você executa decide qual desses números importa. Em leituras em massa, os itens por requisição e o rate limit definem o ritmo: a Sorsa API retorna 100 tweets por requisição a 20 requisições por segundo em todos os planos, até 2.000 tweets por segundo, a partir de US$ 0,014 por 1.000, contra US$ 5,00 na API oficial do X. Comece com as 100 requisições grátis, que nunca expiram, e veja como a API se encaixa nas leituras que você executa. Vai escolher por mais do que velocidade? Nosso guia sobre como escolher uma API do Twitter apresenta as outras verificações.

#FAQ