Convertendo o limite de taxa da API do Bluesky em posts por hora

O que é o limite de taxa da API do Bluesky?

Todo limite de taxa da API do Bluesky que governa escrita é expresso em pontos, e não em requisições: um PDS do Bluesky dá a cada conta 5,000 pontos por hora e 35,000 pontos por dia, e um CREATE custa 3 pontos, um UPDATE 2 pontos e um DELETE 1 ponto. Requisições que ultrapassam um limite recebem uma resposta HTTP 429.

Quase toda outra API social conta chamadas. O Bluesky conta as operações de registro dentro dessas chamadas, soma por conta (por DID, não por senha de aplicativo nem por token) e aplica o orçamento de pontos por cima de um orçamento de requisições HTTP separado. A página oficial de rate limits diz isso sem rodeios: "These limits are on top of any related HTTP API requests."

Os custos em pontos, direto da documentação:

Tipo de ação	Valor
CREATE	3 pontos
UPDATE	2 pontos
DELETE	1 ponto

A documentação converte isso em registros para exatamente um caso, as curtidas, e para por aí. O resto da conta está abaixo.

Quantos posts por hora uma conta do Bluesky consegue fazer?

Uma conta consegue criar 1,666 registros por hora e 11,666 registros por dia, e um post do Bluesky é um registro. Divida o orçamento pelo custo:

Operação	Pontos por unidade	Por hora (5,000 pts)	Por dia (35,000 pts)
CREATE (post, curtida, repost, seguir)	3	1,666	11,666
UPDATE (putRecord)	2	2,500	17,500
DELETE (descurtir, deixar de seguir, apagar post)	1	5,000	35,000

Os números de CREATE são arredondados para baixo e deixam dois pontos parados a cada hora, já que 5,000 dividido por 3 dá 1,666.67 e 35,000 dividido por 3 dá 11,666.67. A documentação cita 1,666 e 11,666, o que bate.

Agrupar não ajuda nos pontos. Uma única chamada de com.atproto.repo.applyWrites pode carregar muitas escritas de registro, e a documentação é explícita ao dizer que os limites "sum up all of those individual record writes." Onde agrupar ajuda é no orçamento de requisições, tratado mais adiante.

Um post, uma curtida, um repost e um seguir custam os mesmos 3 pontos. As coleções de registros são app.bsky.feed.post, app.bsky.feed.like, app.bsky.feed.repost e app.bsky.graph.follow, e o orçamento não distingue entre elas, então um bot de seguir e um bot de postar bebem do mesmo pote.

Por que o limite diário equivale a apenas sete horas do limite por hora?

O teto diário de 35,000 pontos é exatamente sete vezes o teto por hora de 5,000, então sete horas a todo vapor esgotam o dia inteiro. A página da documentação nunca diz isso, e é a coisa mais útil de saber antes de escrever um agendador.

Se o teto por hora fosse a única restrição, um dia permitiria 5,000 vezes 24, ou 120,000 pontos. O teto diário é 29 por cento disso. O teto por hora é uma cota de pico, e o teto diário é o orçamento de verdade.

A taxa sustentável é o que importa para qualquer coisa que rode continuamente:

Janela	Pontos	CREATEs
Pico, uma hora	5,000	1,666
Sustentado, por hora ao longo de 24 h	1,458	486
Sustentado, por minuto	24	8

Essa última linha é o número em torno do qual projetar. 11,666 creates ao longo de 1,440 minutos dão 8.1 por minuto, uma escrita a cada 7.4 segundos. Um worker mais rápido que isso está pegando emprestado do resto do dia, e um worker no teto por hora fica sem orçamento na oitava hora.

Quanto custa de verdade uma thread, uma edição ou um post apagado?

Uma thread custa 3 pontos por post nela, porque cada post de uma thread é um registro próprio. Nada na estrutura de respostas é de graça. Aqui está a conta para os padrões de escrita que as pessoas realmente usam:

Padrão	Pontos	Por hora	Por dia
Um post	3	1,666	11,666
Thread de cinco posts	15	333	2,333
Postar e depois editar (createRecord mais putRecord)	5	1,000	7,000
Postar e depois apagar	4	1,250	8,750
Curtir e depois descurtir	4	1,250	8,750

Imagens e vídeo mudam a contagem de requisições, não a de pontos. Subir um blob por com.atproto.repo.uploadBlob não é uma escrita de registro, então custa zero pontos: um post com quatro imagens são cinco requisições HTTP e 3 pontos. Os tetos de tamanho de blob e o limite de 300 grafemas no texto do post são assuntos separados, e nenhum deles encosta no orçamento de escrita.

Qual limite chega primeiro, o orçamento de pontos ou o de requisições?

Para uma conta sozinha o orçamento de pontos chega primeiro, e para uma frota de contas dividindo um IP o orçamento de requisições chega primeiro. O Bluesky aplica os dois ao mesmo tempo: 3,000 requisições a cada cinco minutos medidas por IP, em todos os endpoints, e o orçamento de pontos medido por conta.

Converta o limite de requisições para as mesmas unidades. 3,000 a cada cinco minutos são 600 por minuto e 36,000 por hora. Uma conta escrevendo a todo vapor faz 1,666 creates por hora, um vinte avos da cota do IP, então um bot solitário nunca vê o limite de IP.

Agora coloque várias contas atrás de um IP. Distribuído por igual, uma conta no seu teto por hora faz 1,666 dividido por 12, ou 138.8 requisições de escrita por janela de cinco minutos. Divida 3,000 por 138.8 e você chega a 21.6. Vinte e uma contas cabem sob o teto de IP com 2,915 requisições, e a vigésima segunda o ultrapassa com 3,054. Esse ponto de virada não está publicado em lugar nenhum, e é por isso que automação multiconta a partir de um servidor se comporta diferente do mesmo código em uma conta só. A documentação não diz como os dois orçamentos interagem quando colidem, apenas que ambos existem.

Quais são os limites de login e por que eles mordem antes dos de escrita?

com.atproto.server.createSession tem teto de 30 a cada 5 minutos e 300 por dia por conta, o que é 39 vezes mais rígido que o orçamento de escrita que ele libera. Uma automação que faz login do zero para cada post tem um teto real de 300 posts por dia, e não 11,666, porque 11,666 dividido por 300 dá 38.9.

O conjunto completo de limites de conta e identidade segundo a documentação:

Endpoint	Medido por	Limite
Requisições de API no total	IP	3,000 a cada 5 minutos
com.atproto.identity.updateHandle	conta	10 a cada 5 minutos, 50 por dia
com.atproto.server.createAccount	IP	100 a cada 5 minutos
com.atproto.server.createSession	conta	30 a cada 5 minutos, 300 por dia
com.atproto.server.deleteAccount	IP	50 a cada 5 minutos
com.atproto.server.resetPassword	IP	50 a cada 5 minutos

Logins que falham são medidos à parte e de forma bem mais dura, e a documentação não menciona isso em momento algum. Em 10 de setembro de 2026, uma requisição com.atproto.server.createSession para bsky.social com credenciais inválidas retornou:

HTTP/2 401
ratelimit-limit: 10
ratelimit-remaining: 9
ratelimit-policy: 10;w=86400

{"error":"AuthenticationRequired","message":"Invalid identifier or password"}

Mais duas tentativas falhas derrubaram ratelimit-remaining para 8 e depois 7, ou seja, o contador está vivo. Uma janela de 86,400 segundos são 24 horas: dez senhas erradas por dia, contra uma cota documentada de createSession de 300. Queime dez tentativas depurando uma senha de aplicativo e você fica trancado para fora desse endpoint até o timestamp de reset, sem nenhuma página no site da documentação explicando por quê.

A documentação também não publica limite para com.atproto.server.refreshSession, o endpoint que um cliente bem-comportado deveria chamar em vez de createSession. Guarde o token de refresh, renove a sessão, e o teto de 300 por dia deixa de ser a sua restrição.

Contornar o teto de login

1

Chame createSession uma vez. Conta contra 30 a cada 5 minutos e 300 por dia.

2

Guarde o token de atualização. Em vez da senha.

3

Use refreshSession para renovar. Sem fazer login de novo.

4

O teto de 300 por dia deixa de valer. refreshSession não tem limite documentado.

Quais cabeçalhos de rate limit o Bluesky realmente envia?

As respostas de um PDS do Bluesky carregam quatro cabeçalhos: ratelimit-limit, ratelimit-remaining, ratelimit-reset e ratelimit-policy. A página de rate limits nunca dá nome a eles, dizendo apenas que "Many HTTP API services return rate limit headers on responses. Developers can use those to debug and understand the current limits, or even automate request throughput and backoff." A especificação XRPC do atproto nomeia um cabeçalho, Retry-After, e só como acompanhante opcional de um 429.

Aqui vai uma resposta real. Uma chamada com.atproto.server.describeServer para bsky.social em 10 de setembro de 2026 retornou:

HTTP/2 200
ratelimit-limit: 3000
ratelimit-remaining: 2999
ratelimit-reset: 1789052966
ratelimit-policy: 3000;w=300

ratelimit-policy: 3000;w=300 são os 3,000 a cada 5 minutos documentados, escritos como limite e janela em segundos, o que confirma o número publicado a partir do próprio servidor. ratelimit-reset é um timestamp Unix, não uma quantidade de segundos de espera, então recue até aquele momento em vez de dormir pelo valor dele.

A mesma checagem contra public.api.bsky.app não retornou nenhum cabeçalho ratelimit-, coerente com uma documentação que chama esses endpoints de "generous" sem publicar um número. O orçamento de pontos também não aparece em cabeçalho nenhum, já que não está preso a um endpoint único. Você tem que contar sozinho.

Esses limites valem para toda conta do Bluesky?

Valem para contas hospedadas em instâncias PDS operadas pelo Bluesky. A documentação é cuidadosa nisso: "Bluesky is built on top of an open network (atproto), and other providers in the network are likely to have different rate-limits." Um PDS auto-hospedado define os próprios números, e o relay do Bluesky aplica um teto separado aos servidores que federam, de 50 eventos de stream de repositório por segundo, 2,600 por hora e 21,000 por dia.

A documentação encerra com "All of the limits described here are likely to evolve over time. Hopefully upwards!" Trate cada número daqui como uma leitura feita em 10 de setembro de 2026, e leia os cabeçalhos em tempo de execução em vez de cravar as constantes no código. Note também que docs.bsky.app hoje devolve um 301 para bsky.network preservando o caminho, então o endereço atual da página citada ao longo do texto é https://bsky.network/docs/rate-limits.

O que isso significa se você agenda posts do Bluesky por uma ferramenta?

Ferramentas de agendamento vivem sob o mesmo orçamento de qualquer outro cliente, porque os limites pertencem ao Bluesky e à conta. Uma fila de posts agendados gasta 3 pontos por post dos mesmos 35,000 por dia de onde saem suas curtidas e seguidas manuais. O que um agendador muda é o formato do gasto: posts colocados em um calendário saem espaçados em vez de em rajada, o que mantém você abaixo da taxa sustentada em vez da taxa por hora. O AdaptlyPost cuida do agendamento de posts no Bluesky junto com o agendamento em massa e um calendário de conteúdo, e traz o desempenho de volta pelas análises do Bluesky. Publicar o mesmo item em várias redes com publicação multiconta continua custando 3 pontos do lado do Bluesky, uma vez só, porque é um registro.

Perguntas frequentes

Quantos posts uma conta do Bluesky pode fazer por dia?

11,666 posts por dia, a partir de um orçamento diário de 35,000 pontos a 3 pontos por CREATE. Distribuído por igual ao longo de 24 horas, isso dá 486 posts por hora, ou um a cada 7.4 segundos. O teto por hora de 1,666 posts é uma cota de pico, e alcançá-lo sete vezes esgota o dia.

Uma curtida conta no mesmo limite de taxa do Bluesky que um post?

Sim. Uma curtida cria um registro app.bsky.feed.like, que é um CREATE de 3 pontos, igual a um post. Posts, curtidas, reposts e seguidas bebem todos do mesmo orçamento de 5,000 pontos por hora por conta.

Qual status HTTP o Bluesky retorna quando você excede um limite de taxa?

HTTP 429, descrito pela documentação como "Too Many Requests." A especificação XRPC do atproto diz que uma resposta 429 "may be a Retry-After header indicating a specific back-off time period." Nos endpoints de PDS, confira ratelimit-reset para o timestamp Unix em que a janela se libera.

Por que meu login no Bluesky falha depois de poucas senhas erradas?

Chamadas de com.atproto.server.createSession que falham em bsky.social retornam ratelimit-policy: 10;w=86400, ou seja, 10 tentativas a cada 24 horas, com o corpo de erro {"error":"AuthenticationRequired","message":"Invalid identifier or password"}. Esse limite não está listado na página de rate limits. Os 30 a cada 5 minutos e 300 por dia documentados valem para sessões bem-sucedidas.

Agrupar escritas com applyWrites economiza orçamento de limite de taxa?

Economiza requisições HTTP, não pontos. A documentação afirma que com.atproto.repo.applyWrites "can write to many records in a single API call" e que os limites "sum up all of those individual record writes." Vinte e cinco creates em uma chamada custam 75 pontos e uma requisição.

Os limites de taxa do Bluesky valem para servidores PDS auto-hospedados?

Os números publicados valem para instâncias PDS operadas pelo Bluesky. Outros provedores no atproto definem os seus, nas palavras da documentação "likely to have different rate-limits." O relay do Bluesky aplica sim um teto próprio a qualquer PDS que federe, de 50 eventos de stream de repositório por segundo, 2,600 por hora e 21,000 por dia, além de 100 contas no máximo e 5 criadas por segundo por padrão.

Quantas contas do Bluesky podem compartilhar um IP antes de bater no limite de requisições?

Vinte e uma contas escrevendo no teto por hora atrás do mesmo IP cabem sob o limite de 3,000 requisições a cada cinco minutos, com 2,915 requisições. Uma vigésima segunda conta ultrapassa, com 3,054. Essa virada só aparece quando várias contas dividem um servidor, já que uma conta sozinha usa 139 das 3,000 requisições.

Enviar imagens ou vídeo para o Bluesky gasta pontos do orçamento?

Enviar um blob por com.atproto.repo.uploadBlob custa zero pontos, porque não é uma escrita de registro. Um post com quatro imagens gasta 3 pontos pelo registro do post e soma mais quatro requisições HTTP, uma por imagem, cinco requisições no total. O orçamento de pontos só conta CREATE, UPDATE e DELETE em registros, não os envios de blob.

O que o cabeçalho ratelimit-reset realmente indica?

ratelimit-reset é um timestamp Unix que marca quando a janela atual termina, não uma contagem de segundos para esperar. Uma resposta de com.atproto.server.describeServer em 10 de setembro de 2026 trouxe ratelimit-reset: 1789052966 junto com ratelimit-limit: 3000 e ratelimit-remaining: 2999. Espere até esse instante em vez de dormir esse número como segundos, e o cabeçalho Retry-After da especificação atproto é um campo separado e opcional, enviado só junto com um 429.

Com que frequência dá para trocar o handle do Bluesky sem bater num limite de taxa?

com.atproto.identity.updateHandle é limitado a 10 trocas a cada 5 minutos e 50 por dia, por conta. Isso é bem mais rígido que o teto de 300 por dia do createSession, então um script que renomeia handles em agenda própria bate nesse limite bem antes de tocar no orçamento de escrita.