O X parou de publicar os rate limits da API do Twitter por plano

Quais são os rate limits da API do Twitter em 2026?

Nada na documentação atual do X define os rate limits da API do Twitter por plano. As tabelas no ar são organizadas por endpoint e divididas em duas colunas, uma para os limites por app, que valem quando você se autentica com um bearer token, e outra para os limites por usuário, que valem com tokens de usuário OAuth 1.0a ou OAuth 2.0. Todo número abaixo vem de docs.x.com/x-api/fundamentals/rate-limits, lido em 12 de setembro de 2026.

As janelas são de 15 minutos, a menos que a entrada diga outra coisa. Estes são os endpoints que um projeto de escuta ou monitoramento realmente toca.

Duas entradas dessa tabela merecem atenção. O recent search dá 450 requisições a um app e só 300 a um usuário, então o bearer token de app é a credencial mais forte para monitorar. O full-archive search é regido tanto por um limite por segundo quanto por um limite por janela, o que significa que um trabalho de backfill precisa de um sleep entre as chamadas em vez de uma rajada seguida de espera.

A quais planos se aplicam os rate limits da API do Twitter?

O X opera dois níveis comerciais agora, pagamento por uso e Enterprise, e os planos de assinatura Free, Basic e Pro que guias antigos ainda citam não existem mais. O changelog data a virada. O X anunciou o piloto de preços por uso em 20 de outubro de 2025 e lançou os preços por uso em 6 de fevereiro de 2026 com Basic e Pro ainda disponíveis, depois migrou os assinantes do Basic após 1º de junho de 2026 e os do Pro após 1º de setembro de 2026. As tabelas de rate limits acima não trazem coluna de plano nenhuma, e essa é a resposta honesta para "quais são os limites no Basic". Não existe Basic.

Onde o X ainda divide por nível, os números ficam assim.

Onde o X se contradiz nesses números?

Três páginas no ar em docs.x.com discordam entre si, e as divergências não são cosméticas.

A primeira é a contagem de regras do filtered stream. A página de introdução ao filtered stream coloca o Enterprise em "25,000+" regras por projeto. A página de preços do Enterprise, descrevendo o mesmo produto, coloca em "5,000+ rules". As duas páginas estavam no ar em 12 de setembro de 2026 e nenhuma aponta para a outra como correção.

A segunda é o tamanho da consulta na contagem de posts. A tabela de rate limits lista /2/tweets/counts/all com a nota "1024 query length". A página do construtor de consultas de contagem diz "Your query can be 512 characters long for pay-per-use customers, or up to 4,096 characters for Enterprise customers", cobrindo os dois endpoints de contagem com um número só. Uma consulta escrita com 1.024 caracteres contra /2/tweets/counts/all fica, portanto, dentro do limite de uma página e fora do limite da outra.

A terceira é uma referência solta. Os dois construtores de consulta de busca e o construtor de regras do filtered stream dizem que seus limites dependem do nível de acesso e apontam para /x-api/getting-started/about-x-api para o detalhe. Essa página não tem mais uma seção de nível de acesso. Ela tem capacidades, versões de API, recursos e preços por uso, e nada que nomeie um plano. A página em docs.x.com/fundamentals/rate-limits carrega a descrição "Understand X API rate limits across access tiers and endpoints" e depois não lista plano nenhum, só um link para a tabela de endpoints.

A lição para quem monta orçamento de um projeto: trate a tabela por endpoint como o documento que vale e as páginas de texto corrido como desatualizadas.

Como ler os headers de rate limit?

O X devolve três headers em cada resposta, e eles são a única fonte de verdade em tempo real.

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

x-rate-limit-limit é o teto da janela atual, x-rate-limit-remaining é o que sobrou e x-rate-limit-reset é um timestamp Unix de quando a janela vira. Passe do teto e você recebe um 429 com este corpo:

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

O erro code: 88 sobreviveu a toda reescrita dessa API desde a v1.1, então vale casar com ele explicitamente, e não só com o código de status. O conselho de recuperação do próprio X é ler x-rate-limit-reset, esperar até aquele timestamp e aplicar backoff exponencial depois disso.

Rate limits são a mesma coisa que a sua conta?

Não, e o X declara a separação direto: rate limits controlam a frequência de requisições para a estabilidade do sistema, enquanto a cobrança por uso cobra pelos dados recuperados. Você pode ficar dentro de todos os rate limits e ainda assim gastar, e pode bater em um rate limit sem gastar nada a mais.

As leituras são cobradas por recurso retornado, não por requisição. Um post lido custa $0.005 e um usuário lido custa $0.010. Os recursos são deduplicados dentro de uma janela de 24 horas UTC, então puxar o mesmo post duas vezes no dia é cobrado uma vez, e o X chama essa deduplicação de garantia fraca, não de promessa. O plano de pagamento por uso tem teto de 3 milhões de posts lidos por ciclo mensal de cobrança, por mais suave que seja o ritmo das suas requisições. O quadro completo de custo, incluindo o lado de escrita, está detalhado na nota sobre os preços da API do X.

Qual limite realmente trava um projeto de monitoramento?

O teto mensal de posts lidos, não o limite de requisições por janela. O recent search a 450 requisições por 15 minutos com 100 resultados por requisição dá 45.000 posts por janela no papel, o que esgotaria uma cota de 3 milhões de posts em menos de um dia de consulta contínua. O teto de requisições é generoso; o teto de recursos é o orçamento.

Isso muda o formato de uma boa consulta. Regras estreitas que retornam poucas correspondências custam pouco, e uma regra ampla que casa com uma palavra comum queima a cota enquanto você dorme. O filtered stream é o instrumento mais barato para cobertura contínua porque entrega só o que casa com suas regras, e manter as regras não custa nada. Escrever bem essas regras é a mesma habilidade de escrever uma boa consulta de busca, assunto da referência sobre os operadores de busca avançada do X.

A outra metade da conta é que o X é uma rede só. Uma pergunta de compra feita no X costuma ser feita também no Reddit e no Hacker News, e essas plataformas medem o acesso de outro jeito, como mostra a comparação dos rate limits da API do Reddit. Equipes que começaram na API do X e depois colocaram preço na lacuna de cobertura acabam escutando várias redes em vez de pagar para alargar uma.

Perguntas frequentes

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

O recent search em /2/tweets/search/recent permite 450 requisições por 15 minutos com um bearer token de app e 300 por 15 minutos com um token de usuário, retornando 10 resultados por padrão e 100 no máximo. O full-archive search em /2/tweets/search/all permite 1 requisição por segundo e 300 por 15 minutos por app, retornando 10 por padrão e 500 no máximo.

O X ainda tem um plano Free?

Não como produto documentado. O X lançou os preços por uso em 6 de fevereiro de 2026 e a documentação atual de acesso guia você pelo cadastro, pela criação de um app e pelo salvamento das credenciais sem nomear plano nenhum. A palavra "Free" sobrevive apenas em entradas do changelog, incluindo a nota de 22 de agosto de 2025 que removeu POST /2/users/:id/likes e POST /2/users/:id/following do plano Free.

O que significa HTTP 429 na API do X?

Significa que você passou de um rate limit daquele endpoint na janela atual. O corpo da resposta traz code: 88 e a mensagem "Rate limit exceeded". Leia o header x-rate-limit-reset para o timestamp Unix em que a janela reinicia, e não tente de novo antes disso.

Os rate limits contam por app ou por usuário?

Os dois, e qual deles se aplica depende de como você autenticou. Requisições com bearer token contam no limite por app, e requisições com token de usuário OAuth 1.0a ou OAuth 2.0 contam no limite por usuário daquela pessoa. Vários endpoints publicam só uma das duas colunas, o que significa que o outro modo de autenticação nem sequer é oferecido ali.

Quantas regras de filtered stream posso rodar?

Um projeto de pagamento por uso recebe 1.000 regras de até 1.024 caracteres cada, por uma conexão única, com entrega limitada a 250 posts por segundo. O Enterprise sobe o tamanho da regra para 2.048 caracteres e permite várias conexões. A contagem de regras do Enterprise é justamente onde as páginas do próprio X discordam, com 25.000+ na introdução ao filtered stream e 5.000+ na página de preços do Enterprise.

Os rate limits valem para o endpoint de uso também?

Sim. GET /2/usage/tweets, o endpoint que reporta o seu próprio consumo de posts, tem teto de 50 requisições por 15 minutos por app e não oferece limite por usuário. Consultar o próprio gasto é barato, mas não escapa da contabilidade, então leia esse endpoint em uma rotina programada em vez de antes de cada chamada.

Quanto custa um Post read na API do X?

Um Post read custa $0,005 e um user read custa $0,010, cobrados por recurso retornado, não por requisição. O X deduplica recursos dentro de uma janela de 24 horas em UTC, então buscar o mesmo Post duas vezes no dia conta uma única vez, embora o X chame essa deduplicação de garantia branda, não de promessa. O plano pay-per-use limita os Post reads a 3 milhões por ciclo de faturamento, não importa o ritmo das requisições.

Quando o X desativou os planos Basic e Pro?

O X lançou o preço pay-per-use em 6 de fevereiro de 2026 com Basic e Pro ainda disponíveis, e depois descontinuou os dois. Os assinantes do Basic migraram após 1º de junho de 2026 e os do Pro após 1º de setembro de 2026, deixando Enterprise e pay-per-use. Guias antigos que ainda citam limites do Basic ou do Pro descrevem uma estrutura de preços que não existe mais.

Por que o rate limit por usuário é maior que o rate limit por app em alguns endpoints?

Não existe uma regra única. Em /2/tweets, um token de app recebe 3.500 requisições a cada 15 minutos enquanto um token de usuário recebe 5.000, e /2/tweets/:id segue o mesmo padrão com 450 contra 900. A busca recente funciona ao contrário, com 450 por app contra 300 por usuário, então a credencial mais forte depende do endpoint chamado, não de uma hierarquia fixa entre autenticação de app e de usuário.

Qual é a forma mais barata de manter monitoramento contínuo no X?

O filtered stream, não o polling de search. A busca recente, com 450 requisições a cada 15 minutos e 100 resultados por chamada, pode retornar até 45.000 Posts por janela no papel, o suficiente para esgotar uma cota mensal de 3 milhões de Posts em menos de um dia de polling contínuo. O filtered stream entrega só o que corresponde às suas regras, e manter essas regras não custa nada, então um conjunto de regras bem definido cobre o mesmo terreno por uma fração dos reads.