Um rate limit define quantas requisições você pode enviar em um intervalo de tempo. Na API oficial do X, cada endpoint tem seu próprio limite a cada 15 minutos, contado separadamente para o seu app e para cada token de usuário. Se passar dele, você recebe HTTP 429 até a janela reiniciar. APIs de terceiros também limitam requisições, geralmente por segundo ou por minuto, somando todos os endpoints.
Este artigo lista os limites oficiais dos endpoints mais usados, explica os headers e a resposta 429 e coloca ao lado os limites publicados de algumas alternativas. Tudo foi verificado em 2026-10-10. Nós operamos a TwittrAPI, uma das alternativas, então leia essa parte sabendo disso.
Como funcionam os rate limits da API do X
A página de rate limits do X descreve três regras:
- Janelas. Os limites reiniciam a cada 15 minutos ou a cada 24 horas. As tabelas dessa página mostram limites de 15 minutos, salvo indicação em contrário.
- Por endpoint. Cada endpoint tem seu próprio limite. Esgotar o limite de busca não afeta o limite de consulta de usuários.
- Por app ou por usuário. Requisições feitas com um Bearer Token só de app contam para o limite do app. Requisições feitas com o token OAuth 1.0a ou OAuth 2.0 de um usuário contam para o limite desse usuário.
Clientes Enterprise têm limites personalizados.
Limites dos endpoints mais usados
Estes são os limites de 15 minutos da mesma página:
| Endpoint | O que faz | Por app | Por usuário |
|---|---|---|---|
GET /2/tweets | Consultar posts por ID | 3.500 | 5.000 |
GET /2/tweets/:id | Consultar um post | 450 | 900 |
GET /2/users/:id | Consultar um usuário por ID | 300 | 900 |
GET /2/users/by/username/:username | Consultar um usuário pelo nome de usuário | 300 | 900 |
GET /2/tweets/search/recent | Buscar posts recentes | 450 | 300 |
GET /2/users/:id/tweets | Posts de um usuário | 10.000 | 900 |
GET /2/users/:id/followers | Seguidores de um usuário | 300 | 300 |
Duas coisas chamam a atenção. Consultas de usuário são limitadas a 300 requisições a cada 15 minutos com um token de app, ou seja, 20 por minuto. Listas de seguidores têm o mesmo limite de 300 para apps e usuários, então puxar os seguidores de muitas contas grandes leva muito tempo, mesmo que você possa pagar.
Rate limits e a conta a pagar são coisas separadas
Desde 2026 a API do X é paga por uso: você compra créditos, e cada post lido custa US$ 0,005 e cada usuário lido US$ 0,010, segundo a página de preços da API do X. Os rate limits não mudam conforme o quanto você gasta. Um saldo maior não dá mais requisições por janela.
Além dos rate limits, existe um teto de uso. O pagamento por uso para em 3 milhões de leituras de posts por ciclo de cobrança mensal e, acima disso, você precisa do Enterprise. A página de preços também diz que um recurso buscado mais de uma vez no mesmo dia UTC só é cobrado uma vez.
Os dois limites se somam. A busca recente retorna no máximo 100 posts por requisição, então 450 requisições em uma janela podem retornar até 45.000 posts, o que custa até US$ 225 pela tarifa de leitura de posts. Repita isso a cada 15 minutos e você chega ao teto de 3 milhões em bem menos de um dia. O artigo preço da API do X em 2026 tem mais exemplos com números.
Headers e a resposta 429
Toda resposta da API do X traz três headers:
| Header | Significado |
|---|---|
x-rate-limit-limit | Requisições permitidas na janela |
x-rate-limit-remaining | Requisições restantes na janela atual |
x-rate-limit-reset | Horário Unix em que a janela reinicia |
Quando acabam as requisições, a API retorna HTTP 429 com o código de erro 88 e a mensagem "Rate limit exceeded". A solução que o X recomenda é ler x-rate-limit-reset e esperar até esse horário. Se não houver horário de reinício, use backoff exponencial. O código de exemplo do X espera pelo menos 60 segundos antes de tentar de novo.
Um pequeno helper em Python que faz isso:
import random
import time
import requests
def get_with_backoff(url, headers, max_tries=5):
for attempt in range(max_tries):
resp = requests.get(url, headers=headers, timeout=30)
if resp.status_code != 429:
return resp
reset = resp.headers.get("x-rate-limit-reset")
retry_after = resp.headers.get("retry-after")
if reset:
wait = max(int(reset) - time.time(), 1)
elif retry_after:
wait = int(retry_after)
else:
wait = min(60 * 2**attempt, 900)
time.sleep(wait + random.uniform(0, 1))
raise RuntimeError("still rate limited after retries")Ele também trata o Retry-After, que várias APIs de terceiros enviam no lugar de um timestamp de reinício. O pequeno atraso aleatório evita que vários workers tentem de novo no mesmo instante.
Limites publicados das alternativas
APIs de terceiros para dados públicos do X definem seus próprios limites. Em geral, eles são contados por conta e somam todos os endpoints, não por endpoint. Estes são os números que cada provedor publica.
twitterapi.io: conforme o status da conta
A página de limites QPS do twitterapi.io diz que contas que nunca pagaram ficam limitadas a 0,2 requisição por segundo, uma a cada 5 segundos. Uma compra avulsa de créditos sobe isso para 20 requisições por segundo. As assinaturas vão de 20 por segundo nos planos mais baixos a 500 por segundo no Business. Quem passa do limite recebe 429 com um header Retry-After, e a página diz que a conta não é bloqueada.
Outras páginas do twitterapi.io trazem números diferentes. A introdução da documentação fala em até 200 QPS por cliente. Citamos a página dedicada aos limites e sugerimos confirmar com eles.
SocialData: 120 requisições por minuto
A página de rate limits do SocialData define 120 requisições por minuto por usuário, compartilhadas entre todos os endpoints, e diz que limites maiores podem ser pedidos de graça por e-mail. A página de erros diz que um 429 significa que você passou do limite e recomenda backoff exponencial. Um 402 significa saldo insuficiente, um problema diferente de rate limit.
RapidAPI: cota do plano mais uma janela por minuto
Qualquer API vendida no RapidAPI, incluindo a nossa, pode ter dois tipos de limite. A documentação de headers de resposta do RapidAPI descreve os dois:
x-ratelimit-requests-limitex-ratelimit-requests-remainingacompanham a cota do seu plano, que reinicia todo dia ou todo mês, conforme o plano.x-ratelimit-limitex-ratelimit-remainingacompanham uma janela de 60 segundos. Quando ela acaba, você recebe 429. Esses headers só aparecem se a API tiver esse limite.
A cota é o que você pagou. A janela por minuto é o que retorna 429 quando você envia rápido demais.
TwittrAPI
No RapidAPI e no JojAPI, os limites de cada plano aparecem na página da API no marketplace. Em contas diretas, os limites dependem da conta; fale com o suporte se precisar de mais vazão. Passou do limite, recebe HTTP 429. A nossa documentação de rate limits (em inglês) explica o backoff, e os SDKs oficiais de Python e Node.js repetem as respostas 429 por você. Contas diretas podem contratar níveis mais altos, até 1.000 requisições por segundo por conta própria, na página de preços; o TwittrAPI for teams (em inglês) cobre mais do que isso.
Cobramos por chamada, a partir de US$ 0,065 por 1.000 chamadas nos preços diretos. Chamadas que falham com 400, 407, 408, 409 ou 5xx são reembolsadas.
Lado a lado
| API oficial do X | twitterapi.io | SocialData | TwittrAPI | |
|---|---|---|---|---|
| Unidade do limite | Requisições por endpoint a cada 15 min (ou 24 h) | Requisições por segundo, por conta | Requisições por minuto, por usuário | Por plano nos marketplaces, por conta no direto |
| Exemplo | 300 consultas de usuário / 15 min por app | 20/s após qualquer compra | 120/min | Veja a página da API ou pergunte ao suporte |
| Acima do limite | 429, código 88 | 429 com Retry-After | 429 | 429 |
| Teto mensal | 3 mi de leituras de posts no pagamento por uso | Não informado na página de limites | Não informado | Cota do plano nos marketplaces; saldo pré-pago no direto |
Como ficar abaixo dos limites
A maioria dos 429 vem de poucos hábitos. Isto ajuda em todas as APIs acima:
- Guarde em cache o que não muda. Perfis e posts antigos mudam pouco. Armazene e busque de novo com uma frequência definida.
- Use endpoints em lote.
GET /2/tweetsaceita muitos IDs e tem o maior limite de consulta da tabela. Algumas APIs de terceiros têm consultas em lote parecidas. - Distribua as requisições. Um ritmo constante abaixo do limite é melhor do que rajadas seguidas de espera.
- Leia os headers. Diminua o ritmo quando o número restante ficar baixo, em vez de esperar o 429.
- No 429, espere e depois continue. Nunca tente de novo em loop apertado. Isso deixa você limitado por mais tempo.
Se você está pensando em fazer scraping do x.com diretamente para fugir dos limites da API, o X também tem limites lá. How to scrape Twitter (X) data in 2026 (em inglês) explica o que você vai encontrar.
Perguntas frequentes
Qual é o rate limit da API do X?
Não existe um número único. Cada endpoint tem seu próprio limite por janela de 15 minutos, contado separadamente por app e por usuário. Por exemplo, a consulta de usuário pelo nome de usuário permite 300 requisições a cada 15 minutos por app e 900 por usuário.
Quanto tempo dura um rate limit da API do X?
Até a janela atual reiniciar, depois de 15 minutos ou 24 horas, conforme o endpoint. O header x-rate-limit-reset informa o horário exato.
O que significa o erro 429 com código 88?
Você enviou mais requisições do que o endpoint permite na janela atual. Espere até o horário em x-rate-limit-reset e continue.
Pagar mais aumenta os rate limits da API do X?
Não no pagamento por uso. O saldo paga as requisições, mas os limites por janela continuam os mesmos. Clientes Enterprise têm limites personalizados.
APIs do Twitter de terceiros têm rate limits?
Sim. Em geral são definidos por conta, por segundo ou por minuto. twitterapi.io, SocialData e os planos do RapidAPI publicam os seus. Para uma chave da TwittrAPI, veja a página da API no marketplace ou pergunte ao suporte se for uma conta direta. A API do Twitter mais barata em 2026 compara os preços, e você pode testar a nossa com US$ 0,50 de crédito de teste em /start.
