Rate limits da API do Twitter (X) em 2026: tabelas e correções

Por Sorsa Editorial

Atualizado em julho de 2026: refeito como referência completa, cobrindo todas as categorias de endpoint da X API v2 (cerca de 100 endpoints, reverificados contra as tabelas oficiais de rate limit do X no fim de julho de 2026). Inclui limites de mídia, itens salvos, Spaces, trends, streaming e webhooks, amplia a seção do plano gratuito e mantém atualizadas a mudança de abril de 2026 para acesso somente Enterprise e o corte dos tetos de conta em maio de 2026.

Em resumo: Os rate limits da X API v2 valem por endpoint, divididos em pools por app (Bearer Token) e por usuário (OAuth), e resetam em janelas de 15 minutos ou 24 horas. A busca recente permite 300 requisições por 15 minutos por usuário; a postagem, 100. Exceder qualquer limite retorna HTTP 429, e o cabeçalho x-rate-limit-reset mostra exatamente quando a janela reabre.

Na verdade, são três sistemas separados que podem barrar as suas requisições, e todos retornam erros parecidos. O seu app de desenvolvedor fica sob os rate limits por endpoint da API do X (antigo Twitter). A conta do X de onde ele posta fica sob tetos de conta separados, hoje tão baixos quanto 50 posts por dia para contas não verificadas. E um saldo de pagamento por uso fica sob um teto mensal de uso de 2 milhões de leituras de posts por cima dos dois. Bater em qualquer um dos três trava você por completo, e é por isso que "estou longe do meu rate limit" é uma reclamação tão comum e confusa.

Este guia cobre as três camadas com números atuais, começando pelas tabelas completas por endpoint. Nós operamos a Sorsa API, uma API alternativa do Twitter (X), então batemos nesses limites e nos 429s que eles produzem todos os dias, tanto nos nossos próprios pipelines quanto nas migrações que conduzimos. Essa é também a razão de termos construído a Sorsa sem eles: um limite fixo de 20 requisições por segundo em todos os endpoints, sem janelas de 15 minutos e sem divisão por app x por usuário para administrar, e leituras a partir de US$ 0,02 por 1.000 tweets nos endpoints em lote contra US$ 5,00 por 1.000 leituras de posts no pagamento por uso oficial, com 100 requisições grátis no cadastro para testar. Os números abaixo são com o que você trabalha na API oficial do X hoje, e mais adiante colocamos os dois modelos lado a lado.

Última verificação: 31 de julho de 2026, contra a documentação oficial de rate limit e de limites de conta do X.

Os limites mais consultados {#the-limits-people-look-up-most}

Se você veio atrás de um número específico, ele provavelmente está nesta tabela. Tudo aparece completo mais adiante.

Índice

• Como funcionam os rate limits da API do X
• Tabelas de rate limit da API do X: cada endpoint
• Rate limits de postagem da API do X: tetos de API x tetos de conta
• Limites do plano gratuito da API do X em 2026
• Quantos tweets dá para puxar de verdade por dia?
• Rate limits padrão x Enterprise
• O que acontece quando você bate em um rate limit (429)
• Como ficar dentro dos rate limits
• Perguntas frequentes

Como funcionam os rate limits da API do X {#how-x-api-rate-limits-work}

Os rate limits da X API v2 são definidos por endpoint, sem um número global único. A maioria dos endpoints reseta em uma janela móvel de 15 minutos; alguns, como postagem e upload de mídia, usam janelas de 24 horas, e alguns endpoints de streaming e de arquivo somam um teto por segundo. A janela começa na sua primeira requisição àquele endpoint, não num horário fixo de relógio, então "300 por 15 minutos" significa 300 requisições em qualquer intervalo móvel de 15 minutos.

Limites por app x por usuário

Cada endpoint rastreia até dois pools independentes:

Os limites por app valem quando você autentica com um Bearer Token (autenticação somente do app). Toda requisição que a sua aplicação faz sai de um pool compartilhado, não importa qual dos seus usuários a disparou. Dez mil usuários acessando o seu backend de uma vez gastam todos do mesmo balde por app.

Os limites por usuário valem quando você autentica com tokens de usuário OAuth 1.0a ou OAuth 2.0. Cada usuário autenticado ganha um balde separado. Com 100 usuários, cada um tem as próprias 300 requisições de busca recente por 15 minutos.

Alguns endpoints expõem os dois pools, outros só um. Nas tabelas abaixo, "n/a" significa que aquele tipo de autenticação não é suportado para aquela chamada.

Lendo os seus limites nos cabeçalhos da resposta

Toda resposta da API do X carrega três cabeçalhos que dizem exatamente onde você está:

x-rate-limit-limit: 900
x-rate-limit-remaining: 847
x-rate-limit-reset: 1705420800

O x-rate-limit-limit é o teto da janela atual. O x-rate-limit-remaining é o que sobrou. O x-rate-limit-reset é um timestamp Unix de quando a janela reseta. Faça o parse desse timestamp, subtraia o horário atual, e você sabe com precisão quantos segundos esperar. Nunca é preciso adivinhar.

Rate limits, tetos de uso e limites da conta

Essa distinção derruba mais desenvolvedores do que qualquer número isolado, então aqui estão as três camadas lado a lado:

Desde que o X migrou para o preço de pagamento por uso no início de 2026, cada recurso que você busca custa dinheiro, e as contas padrão carregam o teto rígido de 2 milhões de leituras de posts por mês. Você pode ficar confortavelmente dentro do seu rate limit de 15 minutos e ainda assim ser bloqueado porque queimou o teto mensal. Para o lado de custo (preços por ação, a janela de deduplicação de 24 horas e o que mudou em 20 de abril de 2026), veja a nossa análise de preços da API do X.

Mais uma distinção: se você é um usuário comum do X e vê "rate limit exceeded" ao rolar o feed ou postar pelo app, isso é o teto do lado da plataforma, não a API de desenvolvedor. Cobrimos esse caso à parte em o que "rate limit exceeded" significa no X e como resolver. Tudo abaixo é para desenvolvedores que chamam a API.

Tabelas de rate limit da API do X: cada endpoint {#x-api-rate-limit-tables-every-endpoint}

A documentação oficial do X lista hoje cerca de 100 endpoints em mais de uma dúzia de categorias. As tabelas abaixo cobrem todos eles, agrupados pelo que você quer fazer, e não pela taxonomia interna de produto do X. Todos os números foram lidos das tabelas oficiais de rate limit do X e reconferidos em 31 de julho de 2026. Os limites são por 15 minutos, salvo indicação em contrário.

Rate limits de busca e de consulta de tweets

A busca merece um olhar mais atento porque se divide em dois endpoints com tetos bem diferentes. A busca recente dá 300 requisições por 15 minutos por usuário, mas só alcança 7 dias para trás, o que cobre a maioria das buscas de tweets rodadas via API. A busca de arquivo completo alcança até 2006, mas trava você em 1 requisição por segundo, então não dá para estourar em rajadas. Se você precisa de profundidade histórica, esse teto rígido de 1/s é o número em torno do qual planejar; explicamos como trabalhar dentro dele no nosso guia de como puxar dados históricos do Twitter.

Rate limits de timeline e de menções

Rate limits de postagem, exclusão e mídia

Os dois números que importam para a maioria das automações de postagem: 100 posts por 15 minutos por usuário e 50 exclusões por 15 minutos por usuário. Os dois são tetos do lado da API; os tetos de conta abaixo costumam pesar antes.

Rate limits de consulta de engajamento (curtidas, retweets, quotes)

Todas as consultas de engajamento ficam em 75 por 15 minutos, um dos tetos de leitura mais apertados da API. Auditar quem deu retweet ou curtiu um post viral esgota isso rápido.

Rate limits de escrita de engajamento (somente Enterprise desde abril de 2026)

A partir de 20 de abril de 2026, o X removeu seguir, curtidas e quotes de todos os planos self-service. Os limites acima continuam nas tabelas do X, mas agora só valem sob um contrato Enterprise. Postagem e mensagens diretas continuam disponíveis no pagamento por uso.

Rate limits de consulta de usuários e de seguidores

Os endpoints de seguidores e de seguindo compartilham um mesmo limite de 300 por 15 minutos nos dois pools. A 1.000 resultados por página, paginar uma conta de um milhão de seguidores leva de 16 a 17 janelas, cerca de quatro horas de relógio. Se puxar listas de seguidores e de seguindo em escala é a sua carga principal, esse ritmo é a restrição em torno da qual desenhar o projeto.

Rate limits de mensagens diretas

A 15 leituras por 15 minutos por usuário, fluxos com uso intenso de DM batem no teto quase de imediato; os tetos de envio por 24 horas tornam a automação aqui deliberadamente lenta.

Rate limits de listas

Os tweets de lista e os membros de lista, a 900 por 15 minutos, estão entre os limites de leitura mais generosos da API, e é por isso que as listas seguem sendo uma solução alternativa popular para monitoramento.

Rate limits de Spaces, trends, Comunidades, analytics e notícias

Rate limits de itens salvos, bloqueios e silenciamentos

Rate limits de streaming e webhooks

Os endpoints de streaming são somente do app. O modelo mental importante: o limite rege as tentativas de conexão e as mudanças de regra, não o volume entregue, e é por isso que uma única conexão de stream saudável ganha de qualquer loop de polling.

Rate limits de compliance e de uso

Rate limits de postagem da API do X: tetos de API x tetos de conta {#x-api-posting-rate-limits-api-caps-vs-account-caps}

O X impõe a postagem em duas camadas separadas em 2026, e a camada da API quase nunca é a que trava você.

O endpoint de escrita da API (/2/tweets) permite 100 posts por 15 minutos por usuário e 10.000 por 24 horas por app. Separadamente, a conta do X de onde você posta está presa a tetos de conta que valem igual na web, no celular e na API. Em maio de 2026, esse teto de conta caiu para 50 posts originais e 200 respostas por dia em contas não verificadas, contra os 2.400 que valiam havia anos.

Essa é a armadilha. Os desenvolvedores leem o limite da API (100 por 15 minutos parece generoso, quase 9.600 por dia por usuário), arquitetam tudo em torno dele e depois o bot para em 50 posts. O limite da API nunca foi a restrição decisiva:

• Conta não verificada + automação por API: o teto de conta de 50 posts originais por dia bate muito antes de a janela da API importar. As respostas têm teto separado de 200 por dia, e é amplamente relatado que reposts e quotes contam para esses 50, embora o X não tenha dito isso de forma direta.
• Conta verificada ou Premium + automação por API: o teto de conta é maior (o X não publica o número exato), então o limite de escrita da API vira o teto real.
• Escala de app: mesmo com muitos usuários verificados, 10.000 posts por 24 horas por app é uma parede rígida para publicação em alto volume.

A documentação de limites de conta do X é explícita ao dizer que esses tetos contam ações de todos os dispositivos, web, celular e API juntos, então o seu script e o seu celular compartilham o mesmo orçamento diário de posts. Os tetos de conta mais automatizados são estes:

Para o quadro completo do lado da conta, incluindo os tetos das contas verificadas, os subintervalos de meia em meia hora e o que mudou em maio de 2026, veja o nosso guia dedicado aos limites de postagem e tetos diários de posts do X.

A postagem é também a única área em que nenhuma alternativa somente leitura ajuda. Provedores como a Sorsa são feitos para ler dados do X em escala, não para escrever neles, então, se o seu trabalho é autopublicar, os endpoints de escrita da API oficial são inevitáveis e esses são os limites com que você convive.

Limites do plano gratuito da API do X em 2026 {#x-api-free-tier-limits-in-2026}

Não há um plano gratuito geral da API do X para novos desenvolvedores em 2026. O plano gratuito independente foi descontinuado quando o pagamento por uso foi lançado em fevereiro de 2026, então contas novas precisam comprar créditos antes de fazer qualquer chamada. O único acesso gratuito que sobrevive é um programa estreito, com aprovação obrigatória, para apps designados de utilidade pública.

Para quem ainda compara com o plano gratuito legado, os rate limits dele sempre foram severos por design:

• Somente escrita. Zero acesso de leitura de posts: sem timelines, sem busca, sem consulta de tweets.
• 17 requisições por 24 horas no endpoint de post, somando por app e por usuário, o que dá cerca de 500 posts por mês na prática, apesar do número de "1.500 posts por mês" que o X divulgava.
• Janelas de 24 horas em vez das janelas de 15 minutos, mais amigáveis, usadas no acesso pago.

Em outras palavras, o plano gratuito nunca teve rate limits úteis para ler dados do X, e agora ele não existe para novos cadastros. O caminho grátis prático para testar leituras hoje passa pelo acesso de terceiros: toda conta nova da Sorsa começa com 100 requisições grátis, uma única vez, sem cartão de crédito, e elas nunca expiram. Elas cobrem todos os 40 endpoints no mesmo limite fixo de 20 requisições por segundo dos planos pagos, o que pelos endpoints em lote basta para até 10.000 tweets ou 20.000 perfis antes de qualquer um pagar qualquer coisa. Para entender como funcionam hoje o acesso e as chaves oficiais, veja o nosso passo a passo de como obter a chave de API do X em 2026.

Quantos tweets dá para puxar de verdade por dia? {#how-many-tweets-can-you-actually-pull-per-day}

Os números de rate limit por si só não dizem muito. O que importa é a vazão: quantos tweets, perfis ou registros de seguidor você consegue coletar de forma realista em um dia. Aqui estão as contas para os cenários mais comuns, supondo autenticação por usuário.

Busca de tweets (recente)

• Rate limit: 300 requisições / 15 minutos = 1.200/hora = 28.800/dia
• Máximo de resultados por requisição: 100
• Teto teórico: 2.880.000 tweets/dia

Isso soa generoso, mas o teto de cobrança do pagamento por uso é de 2 milhões de leituras de posts por mês. Você queimaria a franquia mensal inteira em menos de um dia de busca contínua. O rate limit não é o seu gargalo aqui. O teto mensal é.

Timelines de usuário

• Rate limit: 900 requisições / 15 minutos = 3.600/hora
• Resultados por requisição: ~20 (varia)
• Teto teórico: ~72.000 tweets/hora por conta

Para coletar timelines individuais, os rate limits raramente são a restrição. O limite real é quantos tweets a conta já postou.

Seguidores

• Rate limit: 300 requisições / 15 minutos = 1.200/hora
• Máximo de resultados por página: 1.000
• Teto teórico: 1.200.000 registros de seguidor/hora

O X retorna até 1.000 seguidores por página, o que faz deste um dos seus endpoints de leitura de maior vazão. Para comparação, no modelo de preço fixo da Sorsa o endpoint de seguidores retorna até 200 perfis por requisição, sem janela de 15 minutos, só o limite fixo de 20 requisições por segundo, o que dá cerca de 4.000 perfis por segundo ou por volta de 14,4 milhões por hora. Em grafos de seguidores muito grandes, a diferença se acumula rápido.

O gargalo real, resumido

Para trabalho de leitura intensa em qualquer escala relevante, o teto de cobrança mensal é o que você bate primeiro, não o rate limit. Os rate limits viram o gargalo prático principalmente nas escritas, nas consultas de engajamento com o teto apertado de 75 por janela e nos pipelines de alta concorrência na autenticação somente do app.

Rate limits padrão x Enterprise {#standard-vs-enterprise-rate-limits}

Tudo acima descreve os rate limits padrão (pagamento por uso). O Enterprise é outro mundo. Clientes Enterprise negociam limites sob medida diretamente com o time de vendas do X, e os detalhes não são públicos, mas o formato geral é conhecido:

• Limites por endpoint sob medida, em geral muito mais altos que os padrão
• Tetos mensais de uso maiores ou removidos (o teto de 2 milhões de leituras de posts pode sumir)
• As escritas de engajamento removidas do self-service em abril de 2026 (follows, curtidas, quotes)
• Busca de arquivo completo em concorrência maior, além de acesso à Activity API e a webhooks com limites sob medida

O preço mínimo do Enterprise historicamente começou por volta de US$ 42 mil por mês, embora isso possa ter mudado com a transição para o pagamento por uso. A aprovação é seletiva e o onboarding pode levar semanas.

Quem realmente precisa de Enterprise?

O Enterprise encaixa em grandes plataformas SaaS que revendem dados do X aos próprios clientes, empresas financeiras rodando modelos em tempo real e grupos de pesquisa que processam milhões de posts por mês. Se você precisa ao mesmo tempo de mais de 2 milhões de leituras de posts por mês e de acesso de escrita, o Enterprise é a sua única rota na API oficial.

Para equipes que precisam de alta vazão em operações de leitura sem o preço do Enterprise, essa é exatamente a lacuna que os provedores de terceiros preenchem, e onde construímos a Sorsa para ficar. O nosso limite fixo de 20 requisições por segundo vale em todos os planos, incluindo o Starter de US$ 49/mês, sem tabelas por endpoint e sem janelas de 15 minutos para administrar; o limite pode ser elevado sob solicitação para casos de alto volume por meio do fale com vendas. A troca honesta é que a Sorsa é somente leitura: sem postar, sem DMs, sem escritas de curtida ou de follow. Se tudo o que você precisa é a leitura avulsa mais barata possível e você tolera montar a confiabilidade por conta própria, há opções mais cruas; se você quer acesso de leitura confiável e completo a um preço fixo, é para esse caso que fomos construídos. Para uma comparação mais ampla do mercado, veja o nosso resumo de alternativas à API do X.

Para cargas de leitura especificamente, os dois modelos se alinham assim:

Nos endpoints em lote da Sorsa isso dá a partir de US$ 0,02 por 1.000 tweets, e mesmo na paginação de busca simples fica em torno de US$ 0,10 por 1.000 no plano Pro, contra US$ 5,00 por 1.000 leituras de posts no pagamento por uso oficial. Para coleta de leitura intensa, isso sai até 50x mais barato por leitura, e as janelas por endpoint somem por completo. A razão para ficar na API oficial são as escritas: qualquer coisa que poste, envie DMs ou curta ainda tem de rodar lá, porque a Sorsa é somente leitura por design. O padrão prático que mais vemos é manter as escritas na API oficial e mover a leitura pesada para uma alternativa de preço fixo; o nosso guia de migração cobre fazer essa troca de forma limpa.

O que acontece quando você bate em um rate limit (429) {#what-happens-when-you-hit-a-rate-limit-429}

Quando você excede um rate limit, o X retorna HTTP 429 com este corpo:

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

A resposta ainda inclui os cabeçalhos de rate limit, que é a parte que importa. O x-rate-limit-reset diz exatamente quando a janela reabre, então você nunca precisa dormir às cegas por um intervalo fixo.

Uma estratégia de recuperação adequada

A abordagem ingênua dorme por 15 minutos fixos e tenta de novo. Funciona, mas desperdiça tempo. Uma abordagem melhor lê o timestamp de reset e espera só o que a janela de fato precisa:

import time
import requests

def request_with_rate_limit_handling(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)

        if response.status_code != 429:
            return response

        reset_timestamp = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset_timestamp - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until window resets.")
        time.sleep(wait_seconds + 1)  # +1s buffer

    raise Exception("Rate limit retries exhausted")

Algumas coisas para vigiar:

Não tente de novo na hora. Um loop de retentativa sem atraso queima as suas requisições restantes nos outros endpoints (na autenticação de nível de app) e pode disparar uma limitação mais agressiva.

Não ignore os 429s em pipelines em massa. Num loop de coleta apertado, um 429 pode significar centenas de requisições falhas antes de o seu código notar. Cheque o x-rate-limit-remaining antes de cada requisição e faça uma pausa quando ele cair abaixo de 10 a 20.

Registre as suas requisições restantes. Quando você está depurando problemas de rate limit, um log em série temporal do x-rate-limit-remaining é o artefato mais útil de todos. Ele mostra exatamente qual padrão de chamada está drenando o seu orçamento.

Cheque em qual das três camadas você bateu de verdade. Um 429 com os cabeçalhos de rate limit perto de zero é a janela do endpoint. Um bloqueio que persiste depois de a janela resetar costuma ser o teto mensal de uso ou um teto de conta, e nenhum backoff resolve esses dois.

Como ficar dentro dos rate limits {#how-to-stay-under-rate-limits}

O conselho padrão ("faça cache das respostas" e "use backoff exponencial") não está errado, mas é incompleto. Estes são os movimentos que de fato mudam as contas, tirados das migrações de pipeline que conduzimos.

1. Use endpoints em lote em vez de consultas individuais

O endpoint /2/tweets aceita até 100 IDs de tweets em uma requisição: uma requisição, uma batida de rate limit, 100 tweets de volta. Fazer 100 chamadas individuais de /2/tweets/:id em vez disso gasta 100 batidas de um limite mais apertado (450/15min contra 3.500/15min no lote). A mesma lógica vale para o /2/users, que aceita até 100 nomes de usuário ou IDs.

As APIs de terceiros levam o lote mais longe. O nosso endpoint de tweets em lote aceita 100 URLs ou IDs de tweets por requisição e a nossa consulta de perfis em lote aceita 100 perfis, cada uma contando como uma única requisição da sua cota. Mais táticas para cortar volume de requisições estão nas nossas notas sobre como otimizar o uso da API.

2. Use streaming em vez de polling

Fazer polling do /2/tweets/search/recent a cada 30 segundos significa 2.880 requisições por dia àquele único endpoint. O stream filtrado do X empurra os tweets correspondentes para você em tempo real por uma única conexão persistente: uma conexão, até 250 posts correspondentes por segundo. O porém são as 50 tentativas de conexão por 15 minutos e só 1 conexão ativa por vez, mas, para monitorar palavras-chave ou contas, ele ganha do polling com folga. Vamos mais fundo no nosso guia de monitoramento do Twitter em tempo real.

3. Faça cache dos perfis de usuário com agressividade

Os perfis de usuário mudam devagar. Nomes de exibição, bios e contadores de seguidores se movem em dias, não em minutos. Se o seu app busca dados de usuário junto com os tweets, faça cache dos perfis com um TTL de 12 a 24 horas e pule a chamada em um cache hit. As métricas de engajamento se movem mais rápido, então um TTL de 1 a 6 horas costuma ser o certo para analytics; dashboards em tempo real não têm bom substituto para chamadas frescas.

4. Monitore os cabeçalhos e limite de forma proativa

Não espere um 429 para desacelerar. Rastreie o x-rate-limit-remaining em cada resposta e adicione um limiar suave: quando ele cair abaixo de cerca de 10% do limite, desacelere antes de bater na parede.

remaining = int(response.headers.get("x-rate-limit-remaining", 100))
if remaining < 30:   # soft threshold
    time.sleep(2)    # gentle slowdown before the hard stop

5. Distribua entre métodos de autenticação

Os limites por app e por usuário são pools independentes. Se você autentica com um Bearer Token e com um token de usuário OAuth, você ganha na prática dois baldes para os endpoints que aceitam os dois. A consulta de tweets permite 3.500 por 15 minutos por app e 5.000 por 15 minutos por usuário, então usar os dois soma 8.500 por 15 minutos. Isso só ajuda se a sua arquitetura comporta caminhos de autenticação duplos; é simples no servidor e geralmente impossível em um app só de cliente.

Mais uma ferramenta que vale conhecer antes de queimar cota de verdade: o X oferece um API Playground auto-hospedado (lançado em dezembro de 2025) que emula os endpoints da v2 localmente, com simulação de rate limit inclusive, então você testa o seu backoff e o tratamento de cabeçalhos sem gastar uma única requisição real.

Na prática: uma equipe de análise de fintech que vivia batendo em 429s {#in-practice-a-fintech-analytics-team-that-kept-hitting-429s}

Uma pequena equipe de análise de fintech (cerca de oito engenheiros) chegou até nós depois que o pipeline de dados do X deles vivia travando. Eles faziam polling da busca recente em um loop de 30 segundos para pegar posts que mexem com o mercado, abriam consultas de perfil por autor e não entendiam por que um limite de "300 por 15 minutos" continuava produzindo 429s no meio da coleta. A causa era a de sempre: a autenticação somente do app fazia com que cada consulta de perfil e cada busca saíssem do mesmo pool por app, e só a cadência de polling já gastava a maior parte dele.

Não os tiramos da API oficial para as escritas de que ainda precisavam; movemos a coleta de leitura intensa para um modelo de preço fixo e trocamos o polling por coleta orientada a evento. No preço por recurso da API oficial, esse volume de leitura ficava na zona desconfortável entre o pagamento por uso barato e um contrato Enterprise de US$ 42 mil. Como os nossos planos fixos saem até 50x mais baratos por leitura que a API oficial naquele volume, o lado de leitura da conta deles caiu para a casa das centenas por mês, e os 429s sumiram assim que as janelas por endpoint saíram de cena. O caminho de escrita ficou na API oficial, onde deve ficar.

Perguntas frequentes {#frequently-asked-questions}

Os rate limits da API do X são por usuário ou por app?

Os dois, conforme o endpoint e o seu método de autenticação. A autenticação por Bearer Token (somente do app) usa limites por app, em que toda requisição da sua aplicação compartilha um pool. A autenticação por token de usuário OAuth usa limites por usuário, em que cada usuário autenticado ganha um balde independente. Muitos endpoints publicam um número por app e um por usuário; alguns publicam só um. As tabelas oficiais de rate limit do X especificam qual vale para cada endpoint.

Qual é o rate limit de postagem na API do X?

O endpoint de escrita da API (/2/tweets) permite 100 posts por 15 minutos por usuário e 10.000 por 24 horas por app, e a exclusão tem teto de 50 por 15 minutos por usuário. Na prática, o teto de conta pesa primeiro: uma conta não verificada do X fica limitada a 50 posts originais e 200 respostas por dia somando API, web e celular.

Qual é o rate limit da busca da API do X?

A busca recente (/2/tweets/search/recent) permite 450 requisições por 15 minutos por app e 300 por 15 minutos por usuário, retornando até 100 resultados cada, com um limite de consulta de 512 caracteres. A busca de arquivo completo (/2/tweets/search/all) permite 1 requisição por segundo com um teto de 300 por 15 minutos, retorna até 500 resultados por chamada, alcança 2006 e é só de plano pago.

Quanto duram as janelas de rate limit da API do X?

A maioria dos endpoints da X API v2 usa janelas móveis de 15 minutos. Alguns usam janelas de 24 horas, incluindo o endpoint de postagem (10.000 por 24 horas por app), os uploads de mídia e vários tetos de DM, e alguns endpoints de streaming e de arquivo somam um teto por segundo. Cada janela começa na sua primeira requisição àquele endpoint, não num horário fixo de relógio.

A API do X tem um plano gratuito com rate limits úteis em 2026?

Não. O X descontinuou o plano gratuito independente em fevereiro de 2026, e novos desenvolvedores começam no pagamento por uso, sem franquia gratuita. O plano gratuito legado era somente escrita, com teto de 17 requisições por 24 horas no endpoint de post e zero acesso de leitura de posts, então nunca deu para ler dados do X em escala. O único acesso gratuito hoje é um programa com aprovação obrigatória para apps designados de utilidade pública. Para testar acesso de leitura sem pagar, a Sorsa API inclui 100 requisições grátis no cadastro: uma única vez, sem cartão de crédito, elas nunca expiram e cobrem todos os 40 endpoints.

Os limites de conta do X são a mesma coisa que os rate limits da API?

Não, são sistemas separados. Os rate limits da API regem quão rápido um app de desenvolvedor pode chamar cada endpoint (por exemplo, 100 posts por 15 minutos por usuário). Os limites da conta regem o que uma conta do X pode fazer em toda a plataforma (por exemplo, 50 posts originais por dia em uma conta não verificada). O crucial: os limites da conta contam ações de API também, então posts automatizados e posts manuais compartilham um mesmo orçamento diário.

Dá para elevar os rate limits da API do X sem o Enterprise?

Na API oficial, não. Os rate limits padrão são fixos e só sobem sob um acordo Enterprise. As soluções alternativas disponíveis são o lote (mais dado por requisição), o streaming (evitar polling) e distribuir requisições entre a autenticação de app e a de usuário. Fora da API oficial, provedores de terceiros focados em leitura costumam aplicar um único limite fixo por segundo em vez de janelas por endpoint, e o elevam sob solicitação.

Como desenvolvedores conseguem alta vazão de leitura sem um contrato Enterprise?

A maioria move o trabalho de leitura intensa para uma alternativa à API do Twitter (X) com um rate limit fixo em vez de janelas por endpoint. A Sorsa API, por exemplo, serve todos os seus 40 endpoints de leitura a 20 requisições por segundo em todos os planos, a partir de US$ 0,02 por 1.000 tweets nos endpoints em lote, com planos a partir de US$ 49 por mês. Em escala de leitura, isso sai até 50x mais barato por post lido que o preço por recurso da API oficial, e remove as janelas de 15 minutos e a divisão por app x por usuário que causam a maioria dos 429s em pipelines de coleta.

Primeiros passos {#getting-started}

Se as janelas por endpoint e os 429s acima são o problema do qual você está tentando sair, a forma mais rápida de sentir a diferença é rodar algumas chamadas você mesmo. O nosso playground interativo executa endpoints ao vivo no navegador, sem chave e sem cadastro, para você checar o formato da resposta antes de decidir qualquer coisa. Quando estiver pronto para construir, o início rápido da Sorsa API deixa você autenticado com uma única chave de API em poucos minutos, e toda conta nova inclui 100 requisições grátis: uma única vez, sem cartão de crédito, nunca expiram e válidas em todos os 40 endpoints, o bastante para até 10.000 tweets ou 20.000 perfis pelos endpoints em lote. Depois disso, os planos de preço saem a partir de US$ 0,02 por 1.000 tweets nos endpoints em lote, com planos a partir de US$ 49 por mês no limite fixo de 20 requisições por segundo coberto acima. Sem análise de app, sem handshake OAuth e sem tabelas de rate limit para guardar na cabeça.

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

Como este guia foi preparado: cada número de endpoint aqui foi lido direto das tabelas oficiais de rate limit do X, e os tetos de conta vieram da documentação de limites do X, ambos reconferidos em 31 de julho de 2026, porque esses números mudam sem muito aviso (o X cortou o teto diário de posts de conta não verificada de 2.400 para 50 em maio de 2026 e moveu as escritas de engajamento para acesso somente Enterprise em abril de 2026). As contas de vazão, o código de recuperação de 429 e o enquadramento de "qual limite bate primeiro" vêm do nosso próprio trabalho construindo e operando uma API alternativa do Twitter (X) e das migrações de pipeline de leitura que a nossa equipe conduz, incluindo o caso anônimo de fintech acima (detalhes mesclados e retirados de qualquer coisa identificável). As afirmações de preço e de teto de uso são resumidas da nossa cobertura separada de preços da API do X; para saber quem somos e como falar conosco, veja Sobre a Sorsa. Nenhuma estatística, fonte ou resultado de cliente aqui é inventado.