Convertir el límite de tasa de la API de Bluesky en publicaciones por hora

¿Qué es el límite de tasa de la API de Bluesky?

Cada límite de tasa de la API de Bluesky que gobierna la escritura se expresa en puntos y no en solicitudes: un PDS de Bluesky da a cada cuenta 5,000 puntos por hora y 35,000 puntos por día, y un CREATE cuesta 3 puntos, un UPDATE 2 puntos y un DELETE 1 punto. Las solicitudes que cruzan un límite reciben una respuesta HTTP 429.

Casi todas las demás API sociales cuentan llamadas. Bluesky cuenta las operaciones de registro dentro de esas llamadas, las suma por cuenta (por DID, no por contraseña de aplicación ni por token) y aplica el presupuesto de puntos encima de un presupuesto de solicitudes HTTP aparte. La página oficial de rate limits lo dice sin rodeos: "These limits are on top of any related HTTP API requests."

Los costes en puntos, directos de la documentación:

Tipo de acción	Valor
CREATE	3 puntos
UPDATE	2 puntos
DELETE	1 punto

La documentación traduce eso a registros para exactamente un caso, los me gusta, y ahí se detiene. El resto de la aritmética está más abajo.

¿Cuántas publicaciones por hora puede hacer una cuenta de Bluesky?

Una cuenta puede crear 1,666 registros por hora y 11,666 registros por día, y una publicación de Bluesky es un registro. Divide el presupuesto entre el coste:

Operación	Puntos cada una	Por hora (5,000 pts)	Por día (35,000 pts)
CREATE (publicación, me gusta, repost, seguimiento)	3	1,666	11,666
UPDATE (putRecord)	2	2,500	17,500
DELETE (quitar me gusta, dejar de seguir, borrar publicación)	1	5,000	35,000

Las cifras de CREATE se redondean hacia abajo y dejan dos puntos varados cada hora, ya que 5,000 dividido entre 3 es 1,666.67 y 35,000 dividido entre 3 es 11,666.67. La documentación cita 1,666 y 11,666, lo cual encaja.

Agrupar no ayuda con los puntos. Una sola llamada a com.atproto.repo.applyWrites puede transportar muchas escrituras de registro, y la documentación es explícita en que los límites "sum up all of those individual record writes." Donde sí ayuda agrupar es en el presupuesto de solicitudes, que vemos más abajo.

Una publicación, un me gusta, un repost y un seguimiento cuestan los mismos 3 puntos. Las colecciones de registros son app.bsky.feed.post, app.bsky.feed.like, app.bsky.feed.repost y app.bsky.graph.follow, y el presupuesto no distingue entre ellas, así que un bot de seguimientos y un bot de publicación beben de la misma olla.

¿Por qué el límite diario equivale a solo siete horas del límite por hora?

El techo diario de 35,000 puntos es exactamente siete veces el techo por hora de 5,000, así que siete horas a pleno rendimiento agotan el día entero. La página de documentación nunca dice esto, y es lo más útil que puedes saber antes de escribir un planificador.

Si el techo por hora fuera la única restricción, un día permitiría 5,000 por 24, o sea 120,000 puntos. El tope diario es el 29 por ciento de eso. El techo por hora es una asignación para ráfagas, el techo diario es el presupuesto real.

La tasa sostenible es lo que importa para cualquier cosa que funcione de forma continua:

Ventana	Puntos	CREATEs
Ráfaga, una hora	5,000	1,666
Sostenido, por hora a lo largo de 24 h	1,458	486
Sostenido, por minuto	24	8

Esa última línea es la cifra sobre la que diseñar. 11,666 creates repartidos en 1,440 minutos son 8.1 por minuto, una escritura cada 7.4 segundos. Un worker más rápido que eso está pidiendo prestado al resto del día, y un worker en el techo por hora se queda sin presupuesto en la hora ocho.

¿Cuánto cuesta en realidad un hilo, una edición o una publicación eliminada?

Un hilo cuesta 3 puntos por cada publicación que contiene, porque cada publicación de un hilo es su propio registro. Nada de la estructura de respuestas es gratis. Aquí está la aritmética de los patrones de escritura que la gente ejecuta de verdad:

Patrón	Puntos	Por hora	Por día
Una publicación	3	1,666	11,666
Hilo de cinco publicaciones	15	333	2,333
Publicar y luego editar (createRecord más putRecord)	5	1,000	7,000
Publicar y luego borrar	4	1,250	8,750
Dar me gusta y luego quitarlo	4	1,250	8,750

Las imágenes y el vídeo cambian el número de solicitudes, no el de puntos. Subir un blob por com.atproto.repo.uploadBlob no es una escritura de registro, así que cuesta cero puntos: una publicación con cuatro imágenes son cinco solicitudes HTTP y 3 puntos. Los topes de tamaño de blob y el límite de 300 grafemas en el texto de la publicación son asuntos aparte, y ninguno toca el presupuesto de escritura.

¿Qué límite llega primero, el presupuesto de puntos o el de solicitudes?

Para una sola cuenta llega primero el presupuesto de puntos, y para una flota de cuentas que comparten una IP llega primero el presupuesto de solicitudes. Bluesky aplica ambos a la vez: 3,000 solicitudes cada cinco minutos medidas por IP, en todos los endpoints, y el presupuesto de puntos medido por cuenta.

Convierte el límite de solicitudes a las mismas unidades. 3,000 cada cinco minutos son 600 por minuto y 36,000 por hora. Una cuenta escribiendo a tope logra 1,666 creates por hora, una veinteava parte de la asignación por IP, así que un bot en solitario nunca ve el límite de IP.

Ahora pon varias cuentas detrás de una IP. Repartidas de forma pareja, una cuenta en su techo por hora hace 1,666 dividido entre 12, o sea 138.8 solicitudes de escritura por ventana de cinco minutos. Divide 3,000 entre 138.8 y obtienes 21.6. Veintiuna cuentas caben bajo el techo de IP con 2,915 solicitudes, y la vigesimosegunda lo cruza con 3,054. Ese punto de cruce no está publicado en ninguna parte, y es la razón por la que la automatización multicuenta desde un servidor se comporta distinto que el mismo código en una sola cuenta. La documentación no dice cómo interactúan los dos presupuestos cuando chocan, solo que ambos existen.

¿Cuáles son los límites de inicio de sesión y por qué muerden antes que los de escritura?

com.atproto.server.createSession tiene un tope de 30 cada 5 minutos y 300 por día por cuenta, lo que es 39 veces más estricto que el presupuesto de escritura al que da paso. Una automatización que inicia sesión de cero para cada publicación tiene un techo real de 300 publicaciones al día, no 11,666, porque 11,666 dividido entre 300 es 38.9.

El conjunto completo de límites de cuenta e identidad según la documentación:

Endpoint	Medido por	Límite
Solicitudes de API en total	IP	3,000 cada 5 minutos
com.atproto.identity.updateHandle	cuenta	10 cada 5 minutos, 50 por día
com.atproto.server.createAccount	IP	100 cada 5 minutos
com.atproto.server.createSession	cuenta	30 cada 5 minutos, 300 por día
com.atproto.server.deleteAccount	IP	50 cada 5 minutos
com.atproto.server.resetPassword	IP	50 cada 5 minutos

Los inicios de sesión fallidos se miden aparte y mucho más duro, y la documentación no lo menciona en absoluto. El 10 de septiembre de 2026, una solicitud com.atproto.server.createSession a bsky.social con credenciales inválidas devolvió:

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

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

Dos intentos fallidos más bajaron ratelimit-remaining a 8 y luego a 7, así que el contador está vivo. Una ventana de 86,400 segundos son 24 horas: diez contraseñas erróneas al día, frente a una asignación documentada de createSession de 300. Quema diez intentos depurando una contraseña de aplicación y quedas fuera de ese endpoint hasta la marca de tiempo de reinicio, sin ninguna página en el sitio de documentación que explique por qué.

La documentación tampoco publica límite para com.atproto.server.refreshSession, el endpoint que un cliente bien educado debería usar en lugar de createSession. Guarda el token de refresco, renueva la sesión, y el techo de 300 por día deja de ser tu restricción.

Evitar el techo de inicio de sesión

1

Llama a createSession una vez. Cuenta contra 30 cada 5 minutos y 300 al día.

2

Guarda el token de refresco. En vez de la contraseña.

3

Usa refreshSession para renovar. No vuelvas a iniciar sesión.

4

El límite de 300 al día deja de aplicar. refreshSession no tiene límite documentado.

¿Qué cabeceras de rate limit envía Bluesky en realidad?

Las respuestas de un PDS de Bluesky llevan cuatro cabeceras: ratelimit-limit, ratelimit-remaining, ratelimit-reset y ratelimit-policy. La página de rate limits nunca las nombra y solo dice 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." La especificación XRPC de atproto nombra una cabecera, Retry-After, y solo como acompañante opcional de un 429.

Aquí va una respuesta real. Una llamada com.atproto.server.describeServer a bsky.social el 10 de septiembre de 2026 devolvió:

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

ratelimit-policy: 3000;w=300 son los 3,000 cada 5 minutos documentados, escritos como límite y ventana en segundos, lo que confirma la cifra publicada desde el propio servidor. ratelimit-reset es una marca de tiempo Unix, no un número de segundos de espera, así que retrocede hasta ese momento en lugar de dormir su valor.

La misma comprobación contra public.api.bsky.app no devolvió ninguna cabecera ratelimit-, coherente con que la documentación llame a esos endpoints "generous" sin publicar una cifra. El presupuesto de puntos tampoco aparece en ninguna cabecera, ya que no está atado a un endpoint concreto. Tienes que contarlo tú.

¿Estos límites aplican a todas las cuentas de Bluesky?

Aplican a cuentas alojadas en instancias PDS operadas por Bluesky. La documentación es cuidadosa con esto: "Bluesky is built on top of an open network (atproto), and other providers in the network are likely to have different rate-limits." Un PDS autoalojado fija sus propias cifras, y el relay de Bluesky aplica un techo aparte a los servidores que federan, de 50 eventos de flujo de repositorio por segundo, 2,600 por hora y 21,000 por día.

La documentación cierra con "All of the limits described here are likely to evolve over time. Hopefully upwards!" Trata cada cifra de aquí como una lectura tomada el 10 de septiembre de 2026, y lee las cabeceras en tiempo de ejecución en lugar de fijar las constantes en el código. Ten en cuenta también que docs.bsky.app ahora emite un 301 hacia bsky.network conservando la ruta, así que la dirección actual de la página citada a lo largo del texto es https://bsky.network/docs/rate-limits.

¿Qué significa esto si programas publicaciones de Bluesky con una herramienta?

Las herramientas de programación viven bajo el mismo presupuesto que cualquier otro cliente, porque los límites pertenecen a Bluesky y a la cuenta. Una cola de publicaciones programadas gasta 3 puntos por publicación de los mismos 35,000 por día de los que beben tus me gusta y seguimientos manuales. Lo que cambia un planificador es la forma del gasto: las publicaciones colocadas en un calendario salen espaciadas en lugar de en ráfaga, lo que te mantiene por debajo de la tasa sostenida en vez de la horaria. AdaptlyPost se encarga de la programación de publicaciones en Bluesky junto con la programación masiva y un calendario de contenido, y devuelve el rendimiento con analíticas de Bluesky. Publicar el mismo elemento en varias redes mediante publicación multicuenta sigue costando 3 puntos del lado de Bluesky, una vez, porque es un solo registro.

Preguntas frecuentes

¿Cuántas publicaciones puede hacer una cuenta de Bluesky al día?

11,666 publicaciones al día, a partir de un presupuesto diario de 35,000 puntos a 3 puntos por CREATE. Repartidas de forma pareja a lo largo de 24 horas son 486 publicaciones por hora, o una cada 7.4 segundos. El techo por hora de 1,666 publicaciones es una asignación para ráfagas, y alcanzarlo siete veces agota el día.

¿Un me gusta cuenta contra el mismo límite de tasa de Bluesky que una publicación?

Sí. Un me gusta crea un registro app.bsky.feed.like, que es un CREATE de 3 puntos, igual que una publicación. Publicaciones, me gusta, reposts y seguimientos beben todos del mismo presupuesto de 5,000 puntos por hora y por cuenta.

¿Qué estado HTTP devuelve Bluesky cuando superas un límite de tasa?

HTTP 429, descrito por la documentación como "Too Many Requests." La especificación XRPC de atproto dice que en una respuesta 429 "may be a Retry-After header indicating a specific back-off time period." En los endpoints de PDS, consulta ratelimit-reset para la marca de tiempo Unix en la que se libera la ventana.

¿Por qué mi inicio de sesión en Bluesky falla tras solo unas pocas contraseñas incorrectas?

Las llamadas fallidas de com.atproto.server.createSession a bsky.social devuelven ratelimit-policy: 10;w=86400, que son 10 intentos cada 24 horas, con el cuerpo de error {"error":"AuthenticationRequired","message":"Invalid identifier or password"}. Ese límite no figura en la página de rate limits. Los 30 cada 5 minutos y 300 por día documentados aplican a sesiones exitosas.

¿Agrupar escrituras con applyWrites ahorra presupuesto de límite de tasa?

Ahorra solicitudes HTTP, no puntos. La documentación afirma que com.atproto.repo.applyWrites "can write to many records in a single API call" y que los límites "sum up all of those individual record writes." Veinticinco creates en una llamada cuestan 75 puntos y una solicitud.

¿Los límites de tasa de Bluesky aplican a servidores PDS autoalojados?

Las cifras publicadas aplican a instancias PDS operadas por Bluesky. Otros proveedores de atproto fijan las suyas, en palabras de la documentación "likely to have different rate-limits." El relay de Bluesky sí aplica su propio techo a cualquier PDS que federe, de 50 eventos de flujo de repositorio por segundo, 2,600 por hora y 21,000 por día, más un máximo de 100 cuentas y 5 creadas por segundo por defecto.

¿Cuántas cuentas de Bluesky pueden compartir una IP antes de chocar con el límite de solicitudes?

Veintiuna cuentas escribiendo al máximo por hora desde una misma IP caben bajo el límite de 3,000 solicitudes cada cinco minutos, con 2,915 solicitudes. Una vigésima segunda cuenta lo supera, con 3,054. Ese cruce solo aparece cuando varias cuentas comparten un servidor, ya que una sola cuenta usa 139 de las 3,000 solicitudes.

¿Subir imágenes o video a Bluesky gasta puntos del presupuesto?

Subir un blob mediante com.atproto.repo.uploadBlob cuesta cero puntos, porque no es una escritura de registro. Una publicación con cuatro imágenes gasta 3 puntos por el registro del post y suma cuatro solicitudes HTTP más, una por imagen, cinco solicitudes en total. El presupuesto de puntos solo cuenta CREATE, UPDATE y DELETE sobre registros, no las subidas de blobs.

¿Qué indica en realidad la cabecera ratelimit-reset?

ratelimit-reset es una marca de tiempo Unix que indica cuándo termina la ventana actual, no una cantidad de segundos de espera. Una respuesta de com.atproto.server.describeServer del 10 de septiembre de 2026 devolvió ratelimit-reset: 1789052966 junto con ratelimit-limit: 3000 y ratelimit-remaining: 2999. Espera hasta ese momento en lugar de dormir ese número como si fueran segundos, y ten en cuenta que la cabecera Retry-After de la especificación atproto es un campo aparte y opcional que solo viaja junto a un 429.

¿Con qué frecuencia puedo cambiar mi handle de Bluesky sin chocar con un límite de tasa?

com.atproto.identity.updateHandle está limitado a 10 cambios cada 5 minutos y 50 al día, por cuenta. Eso es mucho más estricto que el tope de 300 al día de createSession, así que un script que renombra handles con calendario propio choca con este límite mucho antes de tocar su presupuesto de escritura.