Rate limit exceeded no Twitter: causas e correções (2026)

Por Sorsa Editorial

Atualizado em 11 de julho de 2026: preços atuais de leitura por recurso da API do X e o teto de 2 milhões de leituras de post verificados contra a documentação de preços do X, mais os tetos de leitura no app de 2026 amplamente reportados para contas gratuitas e Premium.

Em resumo: "Rate limit exceeded" no Twitter (X) significa que você fez mais requisições do que a janela atual permite, então a ação é bloqueada por um instante. Usuários comuns disparam isso rolando, atualizando ou seguindo rápido demais; desenvolvedores veem HTTP 429 com o código de erro 88. A correção mais rápida é parar e esperar a janela resetar.

A expressão "rate limit exceeded" aponta para dois problemas completamente diferentes, e a correção depende de qual você tem. Se a mensagem apareceu enquanto você rolava ou atualizava o app, você bateu em um teto no nível da plataforma na sua conta. Se ela apareceu em um script ou log de servidor como um HTTP 429, você bateu no rate limit por endpoint da API do X. Este guia cobre os dois, começando por como diferenciá-los.

Para desenvolvedores, a razão pela qual o mesmo 429 fica aparecendo muitas vezes é que três limites separados todos o retornam: a janela de 15 minutos por endpoint, os tetos da própria conta do X e um teto mensal de uso. Nós rodamos 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 de leitura intensa que tratamos. É também por isso que construímos a Sorsa sem o modelo de janela: um limite fixo de 20 requisições por segundo em todo endpoint, sem resets de 15 minutos e sem divisão por-app contra por-usuário para malabarizar, com leituras que saem muito mais barato do que o preço por recurso oficial. Os números abaixo são o que você está enfrentando no X agora, e mais adiante colocamos os dois modelos lado a lado.

Verificado pela última vez: 11 de julho de 2026, contra a documentação de rate limit e de preços do X.

Índice

• Rate limit exceeded: a mensagem no app contra o 429 da API
• Bloqueado enquanto navega no X: causas e quanto dura
• O 429 da API do Twitter (X): status HTTP e código de erro 88
• Em qual limite você bateu? As três camadas por trás de um 429
• A correção imediata: leia o cabeçalho de reset e faça backoff
• Como evitar os rate limits da API do Twitter
• Um plano pago remove o rate limit?
• Na prática: um time de social listening que travava nos 429s
• Perguntas frequentes

Rate limit exceeded: a mensagem no app contra o 429 da API {#rate-limit-exceeded-the-in-app-message-vs-the-api-429}

As mesmas três palavras descrevem duas falhas não relacionadas. Uma é um bloqueio da plataforma em uma conta normal do X, mostrado no app ou no site. A outra é um HTTP 429 retornado a um programa que chama a API do X. Elas têm causas diferentes, comportamento de reset diferente e correções diferentes, então o primeiro passo é casar o seu sintoma com a coluna certa.

Se você é um usuário comum e nunca toca na API de desenvolvedor, apenas as duas primeiras linhas se aplicam a você, e a correção é quase sempre parar e esperar. Se você está construindo contra a API, o 429 é um sinal que você pode ler e ao qual responder em código, que é onde a maior parte deste guia foca. Os dois sistemas são impostos separadamente: uma conta normal e um app de desenvolvedor sacam de orçamentos diferentes, então estar bem em um não te protege no outro.

Bloqueado enquanto navega no X: causas e quanto dura {#blocked-while-browsing-x-causes-and-how-long-it-lasts}

Se a mensagem apareceu enquanto você usava o X normalmente, você cruzou um teto no nível da plataforma atrelado à sua conta, não um limite de API. O X aplica esses tetos a ler, postar, seguir, curtir e mandar mensagem para frear a automação e proteger a infraestrutura. O bloqueio é temporário e some sozinho assim que a janela reseta.

O gatilho mais comum para usuários comuns é o teto diário de leitura introduzido em julho de 2023 e ainda ativo, em forma relaxada, em 2026. O X não publica oficialmente os números exatos, mas as cifras reportadas consistentemente em testes de conta são cerca de 1.000 posts por dia para contas gratuitas não verificadas, cerca de 10.000 para contas Premium verificadas, e cerca de 500 para contas novíssimas não verificadas com menos de um mês. Cada post que passa rolando conta como uma leitura, mesmo os que você não toca, então rolar pesado por um feed rico em mídia é o que geralmente dispara.

Outras ações de conta têm seus próprios tetos. Seguir e deixar de seguir rápido demais (cerca de algumas dezenas por hora é onde os problemas começam), curtir em rajada, enviar muitas mensagens diretas, ou mudar o e-mail da conta mais do que um punhado de vezes por hora podem cada um produzir a mesma mensagem. Apps de terceiros conectados à sua conta fazem chamadas de API em segundo plano e sacam do seu orçamento também, então um agendador, uma ferramenta de análise e um rastreador de seguidores rodando de uma vez podem drená-lo sem nenhuma ação sua.

Quanto dura depende de qual teto você bateu:

• A maioria dos bloqueios baseados em janela some em 15 a 60 minutos assim que a janela móvel passa.
• Tetos diários, incluindo o limite de leitura, resetam à meia-noite UTC.
• Violações repetidas podem estender restrições para 24 a 72 horas em contas sinalizadas.

As correções são simples e principalmente sobre esperar de forma limpa. Pare de atualizar, porque cada nova tentativa pode estender o cooldown. Feche o app ou a aba e se afaste por meia hora. Se você usa clientes de terceiros, deslogue de todos eles, já que as chamadas em segundo plano deles podem ser a causa de verdade. Cheque o Downdetector ou as próprias atualizações de status do X, caso um incidente em toda a plataforma esteja sendo reportado erroneamente como um rate limit. Se o bloqueio persistir por horas, deslogar, limpar os cookies e logar de novo às vezes ajuda. Para o detalhamento completo dos tetos no nível da conta por ação e tipo de conta, nossa referência sobre rate limits de conta e de API do X lista cada um com números atuais.

O 429 da API do Twitter (X): status HTTP e código de erro 88 {#the-twitterx-api-429-http-status-and-error-code-88}

Na API de desenvolvedor, "rate limit exceeded" chega como uma resposta HTTP 429. Significa que você enviou mais requisições a um endpoint do que o limite dele permite dentro da janela atual, então a próxima chamada é rejeitada até a janela resetar. O 429 é o sinal da camada de transporte; o X também retorna um identificador da camada de aplicação no corpo da resposta.

O formato exato depende de qual cliente e versão da API você está chamando, mas todos estes descrevem o mesmo evento:

• Linha de status simples: HTTP 429 Too Many Requests.
• Corpo no estilo v1.1 do X: {"errors":[{"code":88,"message":"Rate limit exceeded"}]}, onde o código 88 é o identificador canônico do X para este erro.
• Corpo no estilo v2 do X: {"title":"Too Many Requests","detail":"Too Many Requests","type":"about:blank","status":429}.
• Tweepy: levanta tweepy.errors.TooManyRequests, que um handler de exceção genérico ao redor das suas chamadas vai capturar.
• Por trás do seu próprio app: o front end muitas vezes substitui o 429 bruto por uma mensagem genérica de "não é possível carregar", então o erro de verdade só aparece nos logs do seu servidor.

Uma vez que você confirmou um status 429 ou o código 88, a embalagem não importa e as mesmas correções se aplicam. O que importa é descobrir em qual limite você de fato cruzou, porque na API atual do X três limites diferentes podem cada um retornar um 429, e a correção é diferente para cada um. Se o erro dispara especificamente durante um fluxo de login em vez de durante leituras, pode não ser um rate limit de forma alguma, mas uma checagem antiautomação; cobrimos isso à parte no nosso guia sobre a mensagem "this request looks like it might be automated".

Em qual limite você bateu? As três camadas por trás de um 429 {#which-limit-did-you-hit-the-three-layers-behind-a-429}

Um único 429 na API do X pode vir de três sistemas separados, e "não estou nem perto do meu rate limit" é uma queixa tão comum porque as pessoas checam uma camada e perdem as outras duas. Ler os cabeçalhos da resposta te diz qual delas te parou.

Camada 1: o rate limit por endpoint. Todo endpoint da API do X v2 tem seu próprio teto em uma janela móvel de 15 minutos (alguns usam janelas de 24 horas), rastreado em dois pools independentes: um limite por-app para autenticação por Bearer Token e um limite por-usuário para tokens de usuário OAuth. A busca recente, por exemplo, permite 300 requisições por 15 minutos por usuário. Dez mil usuários batendo em um backend só de app todos gastam de um pool por-app compartilhado, então um app pode ser estrangulado mesmo quando nenhum usuário isolado está acima do limite pessoal dele. Esta é a camada que os cabeçalhos x-rate-limit-* descrevem.

Camada 2: os tetos da própria conta do X. Separado dos limites da API de desenvolvedor, a conta do X por trás do seu app é vinculada a tetos de toda a plataforma que contam ações da web, do mobile e da API juntas. Uma automação postando pela API saca do mesmo orçamento diário que posts manuais de um celular. Se o seu fluxo age sobre uma conta em vez de apenas ler dados públicos, um teto de conta pode produzir um 429 enquanto o seu orçamento por endpoint ainda mostra espaço.

Camada 3: o teto mensal de uso. Desde que o X migrou para o preço de pagamento por uso em 2026, contas padrão carregam um teto rígido de 2 milhões de leituras de post por mês. Você pode ficar confortavelmente dentro de cada janela de 15 minutos e ainda ser bloqueado porque o teto mensal foi gasto. Rate limits controlam quão rápido você chama; o teto de uso controla quanto você consome por ciclo de cobrança. Eles são rastreados e impostos separadamente.

Aqui está como diferenciá-los em poucos segundos:

Para trabalho de leitura intensa, o teto mensal costuma ser o que você bate primeiro, não o rate limit. A janela por endpoint vira o gargalo de verdade principalmente para escritas e para pipelines de alta concorrência em autenticação só de app. Os números completos por endpoint, pool por pool, vivem na nossa referência de rate limit da API do X, e o lado do custo do teto de 2 milhões está no nosso detalhamento de preços da API do X.

A correção imediata: leia o cabeçalho de reset e faça backoff {#the-immediate-fix-read-the-reset-header-and-back-off}

A forma mais rápida de sair de um rate limit da Camada 1 é esperar exatamente o tempo que a janela precisa, não um intervalo fixo cego. Toda resposta da API do X, incluindo o próprio 429, carrega três cabeçalhos que te dizem onde você está:

x-rate-limit-limit: 900
x-rate-limit-remaining: 12
x-rate-limit-reset: 1783779300

x-rate-limit-limit é o teto para a janela atual. x-rate-limit-remaining é o que você tem sobrando. x-rate-limit-reset é um timestamp Unix de quando a janela reabre. Subtraia o tempo atual desse timestamp e você sabe precisamente quantos segundos esperar. Não há adivinhação envolvida.

A recuperação ingênua dorme fixos 15 minutos e tenta de novo. Funciona mas desperdiça tempo. Um padrão melhor lê o timestamp de reset, espera apenas esse tempo e recorre a backoff exponencial se o cabeçalho estiver ausente:

import time
import requests

def request_with_backoff(url, headers, params=None, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, params=params, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response

        reset = response.headers.get("x-rate-limit-reset")
        if reset:
            wait = max(int(reset) - int(time.time()), 1)
        else:
            wait = delay          # no header: exponential backoff
            delay *= 2
        print(f"429 hit, waiting {wait}s (attempt {attempt + 1}/{max_retries})")
        time.sleep(wait + 1)      # small buffer past the reset

    raise RuntimeError("Rate limit retries exhausted")

Duas regras importam mais do que o código. Não tente de novo instantaneamente, porque um loop de retry apertado queima o seu orçamento restante em outros endpoints (na autenticação só de app) e pode disparar estrangulamento mais pesado. E não ignore os 429s em pipelines em massa: um 429 em um loop de coleta pode significar centenas de requisições falhas antes de o seu código reagir, então cheque x-rate-limit-remaining antes de cada chamada e pause quando ele cair abaixo de cerca de 10 a 20 por cento do limite. Um log de série temporal de x-rate-limit-remaining é o artefato mais útil isolado quando você está depurando qual padrão de chamada drena o orçamento.

Como evitar os rate limits da API do Twitter {#how-to-avoid-twitter-api-rate-limits}

O backoff te tira da janela atual. Ficar longe da parede é sobre gastar menos requisições por unidade de dado. Estes são os movimentos que de fato mudam a conta, tirados das migrações de pipeline de leitura que a nossa equipe trata.

Faça em lote em vez de iterar consultas individuais. O endpoint de tweet em lote do X aceita até 100 IDs de tweet em uma chamada, e o endpoint de usuário até 100 nomes de usuário ou IDs, cada um uma requisição contra um limite de lote mais alto em vez de 100 batidas separadas de um mais apertado. APIs de terceiros levam isso mais longe: nosso endpoint de tweets em massa aceita 100 URLs ou IDs de tweet por requisição e nossa consulta de perfil em lote aceita 100 perfis, cada uma contando como uma única requisição da sua cota.

Faça cache de dados que mudam devagar. Metadados de perfil, contadores de seguidores e resoluções de @ para ID mudam ao longo de dias, não de segundos. Faça cache deles com um TTL de 12 a 24 horas e pule a chamada em um cache hit. As métricas de engajamento mudam mais rápido, então um TTL de 1 a 6 horas é um equilíbrio razoável para análise.

Pagine com cursores, não re-busque. Use o cursor da resposta para buscar a próxima página em vez de rerodar a consulta original. Rerodar busca o mesmo conteúdo pelo qual você já pagou.

Troque polling por streaming onde puder. Fazer polling da busca recente a cada 30 segundos são 2.880 requisições por dia contra um endpoint. O stream filtrado do X empurra os posts que casam por uma única conexão persistente em vez disso. Para provedores sem streaming, o polling rápido em um limite fixo por segundo cobre a maioria das necessidades em tempo real; nós aprofundamos os tradeoffs no nosso guia de monitoramento do Twitter em tempo real.

Divida entre pools de autenticação. Os limites por-app e por-usuário são independentes, então autenticar tanto com um Bearer Token quanto com um token de usuário OAuth te dá dois baldes nos endpoints que aceitam ambos. Isso só ajuda no lado do servidor e costuma ser impossível em um app só de cliente.

A correção estrutural, se você continua batendo na parede em trabalho de leitura intensa, é sair do modelo de janela por completo. Um rate limit fixo remove o reset de 15 minutos e a divisão por-app contra por-usuário que causam a maioria dos 429s em pipelines de coleta. A Sorsa serve todos os seus 40 endpoints de leitura a um fixo de 20 requisições por segundo em todo plano, e o limite pode ser aumentado para casos de uso de alto volume por fale com o time de vendas.

Um plano pago remove o rate limit? {#does-a-paid-plan-remove-the-rate-limit}

Não. Na API oficial do X, fazer upgrade aumenta o teto; não o remove. Todo nível ainda estrangula por endpoint, e contratos Enterprise (historicamente a partir de cerca de US$ 42.000 por mês) negociam janelas mais altas e tetos de uso levantados em vez de um caminho ilimitado. Não há plano de autoatendimento que remova o rate limiting no X.

Duas rotas estruturais existem se você continua batendo na parede em leituras. Uma é pagar mais ao X por um teto mais alto, o que ainda te deixa dentro do modelo de janela e do teto mensal de 2 milhões de leituras de post. A outra é ler dados públicos do X por uma API de terceiros que não é construída sobre janelas fixas, então o custo escala com o que você puxa em vez de um penhasco de reset rígido. Para uma comparação completa do campo, veja nosso apanhado de alternativas à API do Twitter.

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

Uma requisição da Sorsa retorna até 100 tweets ou até 200 perfis, que é de onde vêm as cifras por 1.000. Em coleta de leitura intensa isso dá até 50x mais barato por leitura do que o preço por recurso oficial, e as janelas de 15 minutos somem por completo. O tradeoff honesto é que a Sorsa é somente leitura: qualquer coisa que poste, envie DMs ou curta ainda roda na API oficial, porque esse é o caminho conforme para escritas. O padrão comum que vemos é manter as escritas no X e mover a leitura intensa para um provedor de tarifa fixa, que o nosso guia de migração percorre.

Outras APIs de terceiros também removem o teto de janela do X, mas a maioria é de pagamento por uso medido em vez de fixo. A TwitterAPI.io, por exemplo, cobra cerca de US$ 0,15 por 1.000 tweets e cerca de US$ 0,18 por 1.000 perfis (checado em julho de 2026). O preço medido mata o 429 de janela fixa, mas a conta ainda escala com o volume e não é fixa de antemão. Os planos fixos da Sorsa mantêm o custo mensal previsível e caem mais barato por leitura, a partir de US$ 0,02 por 1.000 tweets nos endpoints de lote.

Na prática: um time de social listening que travava nos 429s {#in-practice-a-social-listening-team-that-kept-stalling-on-429s}

Uma ferramenta de social listening de médio porte (cerca de uma dúzia de engenheiros) chegou até nós depois que a coleta deles no X vivia travando no meio da execução. Eles estavam fazendo polling da busca recente em um loop apertado para pegar menções de marca para os próprios clientes, e depois espalhando para consultas de perfil por autor, e não conseguiam entender por que um limite de "300 por 15 minutos" ficava produzindo 429s. A causa era a de sempre: a autenticação só de app significava que cada busca e cada consulta de perfil sacavam do mesmo pool por-app, e a cadência de polling sozinha estava gastando a maior parte dele antes de o fan-out sequer começar.

Não os movemos da API oficial para nada que escreviam; movemos a coleta de leitura intensa para um modelo de tarifa fixa e trocamos o polling por coleta orientada a eventos. No preço por recurso, aquele volume de leitura ficava na zona desconfortável entre o pagamento por uso barato e um contrato Enterprise de US$ 42 mil. A conta de leitura deles caiu mais de 90 por cento, e os 429s sumiram assim que as janelas de 15 minutos e a divisão por-app contra por-usuário saíram de cena. O tipo de acompanhamento contínuo de menções de marca que eles rodam é exatamente para o que a nossa solução de social listening é feita.

Perguntas frequentes {#faq}

Por que o Twitter diz "rate limit exceeded"?

O Twitter (X) mostra "rate limit exceeded" quando você faz mais requisições do que um teto permite dentro de uma janela de tempo definida, então ele bloqueia a ação até a janela resetar. Para usuários comuns o gatilho costuma ser ler, rolar, seguir ou curtir rápido demais. Para desenvolvedores é um HTTP 429 da API, onde o limite por janela de um endpoint, um teto de conta ou o teto mensal de uso foi cruzado.

Quanto dura um rate limit do Twitter?

A maioria dos rate limits do Twitter (X) é curta. Bloqueios no app por rolar ou por ações rápidas tipicamente somem em 15 a 60 minutos assim que a janela móvel passa, e tetos diários resetam à meia-noite UTC. Na API, o tempo de reset exato está no cabeçalho de resposta x-rate-limit-reset como um timestamp Unix, geralmente a 15 minutos. Violações repetidas em uma conta podem estender restrições para 24 a 72 horas.

Como evitar os rate limits da API do Twitter?

Gaste menos requisições por unidade de dado. Use endpoints de lote que retornam até 100 itens em uma chamada em vez de iterar consultas individuais, faça cache de dados que mudam devagar como perfis por horas, pagine com cursores em vez de rerodar consultas, e prefira streaming ou polling rápido a loops de polling apertados. A correção estrutural para trabalho de leitura intensa é um rate limit fixo por segundo em vez das janelas de 15 minutos do X.

Um plano pago remove o rate limit do Twitter?

Não. Fazer upgrade de um plano da API oficial do X aumenta o teto mas nunca remove o rate limiting, e todo nível incluindo o Enterprise ainda estrangula por endpoint sob um teto mensal de 2 milhões de leituras de post. Uma alternativa somente leitura como a Sorsa API substitui o modelo de janela por um fixo de 20 requisições por segundo em todo plano, a partir de US$ 0,02 por 1.000 tweets nos endpoints de lote, o que remove o 429 em vez de aumentá-lo.

O rate limit da API do X é por usuário ou por app?

Ambos, dependendo do endpoint e da sua autenticação. A autenticação por Bearer Token usa limites por-app, onde cada requisição da sua aplicação compartilha um pool, então um app pode ser estrangulado mesmo quando nenhum usuário isolado está acima do limite dele. A autenticação por token de usuário OAuth usa limites por-usuário, onde cada usuário autenticado recebe um balde independente. Muitos endpoints publicam as duas cifras.

Por que recebo rate limit se mal fiz requisições?

Geralmente uma de três coisas. O teto é por-app além de por-usuário, então os seus usuários coletivamente estão acima do limite de todo o app. Ou o endpoint que você chamou tem um limite mais apertado do que você espera, então cheque aquele número específico em vez de uma cifra de manchete. Ou um processo em segundo plano, um script esquecido ou o seu teto mensal de uso é a causa de verdade. Logar x-rate-limit-remaining em cada chamada o torna visível.

Primeiros passos

Se os 429s e as janelas de 15 minutos 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. Nosso playground interativo executa endpoints ao vivo no navegador sem chave e sem cadastro, então você pode checar o formato da resposta antes de se comprometer com qualquer coisa. Quando estiver pronto para construir, o quickstart da Sorsa API te autentica com uma única chave de API em um cabeçalho, e toda conta nova começa com 100 requisições grátis: única vez, sem cartão de crédito, que nunca expiram e são válidas em todos os 40 endpoints, o bastante para até 10.000 tweets ou 20.000 perfis pelos endpoints de lote. Além disso, o preço roda a partir de US$ 0,02 por 1.000 tweets nos endpoints de lote, com planos a partir de US$ 49 por mês ao fixo de 20 requisições por segundo. Sem revisão de app, sem handshake OAuth e sem tabelas de rate limit para manter na cabeça.

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

Como este guia foi montado: o formato do 429, os cabeçalhos x-rate-limit-* e o comportamento de janela por endpoint foram verificados contra a documentação oficial de rate limit do X, e os tetos de leitura no app contra a orientação de limites publicada do X e testes de conta atuais, tudo em 11 de julho de 2026, porque esses números mudam sem muito aviso. O diagnóstico de três camadas, o código de recuperação ciente do reset e o enquadramento de vazão vêm do nosso próprio trabalho operando uma API alternativa do Twitter (X) e das migrações de pipeline de leitura que a nossa equipe trata, incluindo o caso anonimizado de social listening acima (detalhes mesclados e retirados de qualquer coisa identificadora). As cifras de preço e de teto de uso são resumidas da nossa cobertura separada de preços da API do X; os preços de concorrentes foram checados na fonte em julho de 2026. Para quem somos e como nos alcançar, veja Sobre a Sorsa. Nenhuma estatística, fonte ou resultado de cliente aqui é inventado.