Convertir la limite de taux de l'API Bluesky en publications par heure

Qu'est-ce que la limite de taux de l'API Bluesky ?

Chaque limite de taux de l'API Bluesky qui régit l'écriture s'exprime en points plutôt qu'en requêtes : un PDS Bluesky accorde à chaque compte 5,000 points par heure et 35,000 points par jour, et un CREATE coûte 3 points, un UPDATE 2 points et un DELETE 1 point. Les requêtes qui franchissent une limite reçoivent une réponse HTTP 429.

Presque toutes les autres API sociales comptent les appels. Bluesky compte les opérations d'enregistrement à l'intérieur de ces appels, les additionne par compte (par DID, pas par mot de passe d'application ni par jeton) et applique le budget de points par-dessus un budget de requêtes HTTP distinct. La page officielle des rate limits le dit directement : « These limits are on top of any related HTTP API requests. »

Les coûts en points, tirés directement de la documentation :

Type d'action	Valeur
CREATE	3 points
UPDATE	2 points
DELETE	1 point

La documentation convertit cela en enregistrements pour exactement un cas, les likes, puis s'arrête. Le reste du calcul est ci-dessous.

Combien de publications par heure un compte Bluesky peut-il faire ?

Un compte peut créer 1,666 enregistrements par heure et 11,666 enregistrements par jour, et une publication Bluesky est un enregistrement. Divisez le budget par le coût :

Opération	Points par unité	Par heure (5,000 pts)	Par jour (35,000 pts)
CREATE (publication, like, repost, abonnement)	3	1,666	11,666
UPDATE (putRecord)	2	2,500	17,500
DELETE (retirer un like, se désabonner, supprimer une publication)	1	5,000	35,000

Les chiffres de CREATE sont arrondis vers le bas et laissent deux points inutilisés chaque heure, puisque 5,000 divisé par 3 fait 1,666.67 et 35,000 divisé par 3 fait 11,666.67. La documentation cite 1,666 et 11,666, ce qui correspond.

Le regroupement n'aide pas pour les points. Un seul appel à com.atproto.repo.applyWrites peut porter de nombreuses écritures d'enregistrement, et la documentation est explicite : les limites « sum up all of those individual record writes. » Ce que le regroupement aide, c'est le budget de requêtes, traité plus bas.

Une publication, un like, un repost et un abonnement coûtent tous les mêmes 3 points. Les collections d'enregistrements sont app.bsky.feed.post, app.bsky.feed.like, app.bsky.feed.repost et app.bsky.graph.follow, et le budget ne fait pas la différence entre elles, donc un bot d'abonnement et un bot de publication puisent dans le même pot.

Pourquoi la limite journalière ne vaut-elle que sept heures de la limite horaire ?

Le plafond journalier de 35,000 points vaut exactement sept fois le plafond horaire de 5,000, donc sept heures à plein régime épuisent la journée entière. La page de documentation ne le dit jamais, et c'est la chose la plus utile à savoir avant d'écrire un planificateur.

Si le plafond horaire était la seule contrainte, une journée autoriserait 5,000 fois 24, soit 120,000 points. Le plafond journalier en représente 29 pour cent. Le plafond horaire est une réserve de rafale, le plafond journalier est le vrai budget.

Le rythme soutenable est ce qui compte pour tout ce qui tourne en continu :

Fenêtre	Points	CREATEs
Rafale, une heure	5,000	1,666
Soutenu, par heure sur 24 h	1,458	486
Soutenu, par minute	24	8

Cette dernière ligne est le chiffre autour duquel concevoir. 11,666 creates répartis sur 1,440 minutes font 8.1 par minute, une écriture toutes les 7.4 secondes. Un worker plus rapide que cela emprunte sur la suite de la journée, et un worker au plafond horaire est à sec dès la huitième heure.

Que coûtent vraiment un fil, une modification ou une publication supprimée ?

Un fil coûte 3 points par publication qu'il contient, parce que chaque publication d'un fil est son propre enregistrement. Rien dans la structure de réponse n'est gratuit. Voici le calcul pour les schémas d'écriture que les gens utilisent vraiment :

Schéma	Points	Par heure	Par jour
Une publication	3	1,666	11,666
Fil de cinq publications	15	333	2,333
Publier, puis modifier (createRecord plus putRecord)	5	1,000	7,000
Publier, puis supprimer	4	1,250	8,750
Liker, puis retirer le like	4	1,250	8,750

Les images et la vidéo changent le nombre de requêtes, pas le nombre de points. Téléverser un blob via com.atproto.repo.uploadBlob n'est pas une écriture d'enregistrement, donc cela coûte zéro point : une publication avec quatre images fait cinq requêtes HTTP et 3 points. Les plafonds de taille de blob et la limite de 300 graphèmes sur le texte de la publication sont des sujets distincts, et aucun ne touche au budget d'écriture.

Quelle limite arrive en premier, le budget de points ou le budget de requêtes ?

Pour un compte unique, le budget de points arrive en premier, et pour une flotte de comptes partageant une IP, c'est le budget de requêtes. Bluesky applique les deux en même temps : 3,000 requêtes par tranche de cinq minutes mesurées par IP, tous endpoints confondus, et le budget de points mesuré par compte.

Convertissez la limite de requêtes dans les mêmes unités. 3,000 par tranche de cinq minutes font 600 par minute et 36,000 par heure. Un compte qui écrit à fond réalise 1,666 creates par heure, un vingtième de la réserve par IP, donc un bot solitaire ne voit jamais la limite d'IP.

Mettez maintenant plusieurs comptes derrière une IP. Réparti uniformément, un compte à son plafond horaire fait 1,666 divisé par 12, soit 138.8 requêtes d'écriture par fenêtre de cinq minutes. Divisez 3,000 par 138.8 et vous obtenez 21.6. Vingt et un comptes tiennent sous le plafond d'IP à 2,915 requêtes, le vingt-deuxième le franchit à 3,054. Ce point de bascule n'est publié nulle part, et c'est pourquoi l'automatisation multicompte depuis un seul serveur se comporte différemment du même code sur un seul compte. La documentation ne dit pas comment les deux budgets interagissent quand ils entrent en collision, seulement que les deux existent.

Quelles sont les limites de connexion et pourquoi mordent-elles avant celles d'écriture ?

com.atproto.server.createSession est plafonné à 30 par tranche de 5 minutes et 300 par jour et par compte, ce qui est 39 fois plus strict que le budget d'écriture auquel il donne accès. Une automatisation qui se reconnecte à neuf pour chaque publication a un vrai plafond de 300 publications par jour, pas 11,666, car 11,666 divisé par 300 fait 38.9.

L'ensemble complet des limites de compte et d'identité selon la documentation :

Endpoint	Mesuré par	Limite
Requêtes API globales	IP	3,000 par 5 minutes
com.atproto.identity.updateHandle	compte	10 par 5 minutes, 50 par jour
com.atproto.server.createAccount	IP	100 par 5 minutes
com.atproto.server.createSession	compte	30 par 5 minutes, 300 par jour
com.atproto.server.deleteAccount	IP	50 par 5 minutes
com.atproto.server.resetPassword	IP	50 par 5 minutes

Les connexions échouées sont mesurées séparément et bien plus durement, et la documentation n'en parle pas du tout. Le 10 septembre 2026, une requête com.atproto.server.createSession vers bsky.social avec des identifiants invalides a renvoyé :

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

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

Deux tentatives échouées de plus ont fait passer ratelimit-remaining à 8 puis à 7, le compteur est donc bien actif. Une fenêtre de 86,400 secondes fait 24 heures : dix mauvais mots de passe par jour, contre une réserve documentée de 300 pour createSession. Brûlez dix tentatives à déboguer un mot de passe d'application et vous êtes exclu de cet endpoint jusqu'à l'horodatage de réinitialisation, sans aucune page du site de documentation pour expliquer pourquoi.

La documentation ne publie non plus aucune limite pour com.atproto.server.refreshSession, l'endpoint qu'un client bien élevé devrait appeler à la place de createSession. Stockez le jeton de rafraîchissement, renouvelez la session, et le plafond de 300 par jour cesse d'être votre contrainte.

Contourner le plafond de connexion

1

Appeler createSession une fois. Compte pour 30 toutes les 5 minutes et 300 par jour.

2

Stocker le jeton de rafraîchissement. Plutôt que le mot de passe.

3

Utiliser refreshSession pour renouveler. Sans se reconnecter.

4

Le plafond de 300 par jour ne s'applique plus. refreshSession n'a pas de limite documentée.

Quels en-têtes de rate limit Bluesky envoie-t-il réellement ?

Les réponses d'un PDS Bluesky portent quatre en-têtes : ratelimit-limit, ratelimit-remaining, ratelimit-reset et ratelimit-policy. La page des rate limits ne les nomme jamais et se contente de dire : « 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 spécification XRPC d'atproto nomme un en-tête, Retry-After, et seulement comme compagnon facultatif d'un 429.

Voici une réponse réelle. Un appel com.atproto.server.describeServer vers bsky.social le 10 septembre 2026 a renvoyé :

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

ratelimit-policy: 3000;w=300, ce sont les 3,000 par tranche de 5 minutes documentés, écrits comme une limite et une fenêtre en secondes, ce qui confirme le chiffre publié depuis le serveur lui-même. ratelimit-reset est un horodatage Unix, pas un nombre de secondes d'attente, alors patientez jusqu'à cet instant plutôt que de dormir la durée de sa valeur.

La même vérification sur public.api.bsky.app n'a renvoyé aucun en-tête ratelimit-, ce qui colle avec une documentation qui qualifie ces endpoints de « generous » sans publier de chiffre. Le budget de points n'apparaît lui non plus dans aucun en-tête, puisqu'il n'est pas rattaché à un endpoint unique. Vous devez le compter vous-même.

Ces limites s'appliquent-elles à tous les comptes Bluesky ?

Elles s'appliquent aux comptes hébergés sur des instances PDS exploitées par Bluesky. La documentation est prudente là-dessus : « 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 auto-hébergé fixe ses propres chiffres, et le relais Bluesky applique un plafond distinct aux serveurs qui fédèrent, à 50 événements de flux de dépôt par seconde, 2,600 par heure et 21,000 par jour.

La documentation se termine sur « All of the limits described here are likely to evolve over time. Hopefully upwards! » Traitez chaque chiffre présenté ici comme un relevé pris le 10 septembre 2026, et lisez les en-têtes à l'exécution plutôt que de coder les constantes en dur. Notez aussi que docs.bsky.app renvoie désormais un 301 vers bsky.network en conservant le chemin, si bien que l'adresse actuelle de la page citée tout au long est https://bsky.network/docs/rate-limits.

Qu'est-ce que cela change si vous programmez vos publications Bluesky avec un outil ?

Les outils de programmation vivent sous le même budget que n'importe quel autre client, parce que les limites appartiennent à Bluesky et au compte. Une file de publications programmées dépense 3 points par publication sur les mêmes 35,000 par jour où puisent vos likes et abonnements manuels. Ce qu'un planificateur change, c'est la forme de la dépense : les publications posées sur un calendrier partent espacées plutôt qu'en rafale, ce qui vous maintient sous le rythme soutenu au lieu du rythme horaire. AdaptlyPost gère la programmation de publications Bluesky aux côtés de la programmation en masse et d'un calendrier de contenu, et relit les performances via les analyses Bluesky. Publier le même élément sur plusieurs réseaux grâce à la publication multicompte coûte toujours 3 points côté Bluesky, une seule fois, parce que c'est un seul enregistrement.

Foire aux questions

Combien de publications un compte Bluesky peut-il faire par jour ?

11,666 publications par jour, à partir d'un budget quotidien de 35,000 points à 3 points par CREATE. Réparti uniformément sur 24 heures, cela fait 486 publications par heure, soit une toutes les 7.4 secondes. Le plafond horaire de 1,666 publications est une réserve de rafale, et l'atteindre sept fois épuise la journée.

Un like compte-t-il dans la même limite de taux Bluesky qu'une publication ?

Oui. Un like crée un enregistrement app.bsky.feed.like, soit un CREATE à 3 points, exactement comme une publication. Publications, likes, reposts et abonnements puisent tous dans le même budget horaire de 5,000 points par compte.

Quel statut HTTP Bluesky renvoie-t-il quand vous dépassez une limite de taux ?

HTTP 429, décrit par la documentation comme « Too Many Requests. » La spécification XRPC d'atproto indique qu'une réponse 429 « may be a Retry-After header indicating a specific back-off time period. » Sur les endpoints PDS, consultez ratelimit-reset pour l'horodatage Unix auquel la fenêtre se libère.

Pourquoi ma connexion Bluesky échoue-t-elle après seulement quelques mauvais mots de passe ?

Les appels com.atproto.server.createSession échoués vers bsky.social renvoient ratelimit-policy: 10;w=86400, soit 10 tentatives par 24 heures, avec le corps d'erreur {"error":"AuthenticationRequired","message":"Invalid identifier or password"}. Cette limite ne figure pas sur la page des rate limits. Les 30 par 5 minutes et 300 par jour documentés concernent les sessions réussies.

Regrouper les écritures avec applyWrites économise-t-il du budget de limite de taux ?

Cela économise des requêtes HTTP, pas des points. La documentation précise que com.atproto.repo.applyWrites « can write to many records in a single API call » et que les limites « sum up all of those individual record writes. » Vingt-cinq creates dans un seul appel coûtent 75 points et une requête.

Les limites de taux Bluesky s'appliquent-elles aux serveurs PDS auto-hébergés ?

Les chiffres publiés valent pour les instances PDS exploitées par Bluesky. Les autres fournisseurs sur atproto fixent les leurs, selon les mots de la documentation « likely to have different rate-limits. » Le relais Bluesky applique bel et bien son propre plafond à tout PDS qui fédère, à 50 événements de flux de dépôt par seconde, 2,600 par heure et 21,000 par jour, plus 100 comptes maximum et 5 créés par seconde par défaut.

Combien de comptes Bluesky peuvent partager une IP avant d'atteindre la limite de requêtes ?

Vingt-et-un comptes qui écrivent à plein régime derrière une même IP restent sous la limite de 3,000 requêtes par cinq minutes, à 2,915 requêtes. Un vingt-deuxième compte la dépasse, à 3,054. Ce basculement n'apparaît que lorsque plusieurs comptes partagent un serveur, puisqu'un seul compte n'utilise que 139 des 3,000 requêtes.

L'envoi d'images ou de vidéos sur Bluesky consomme-t-il des points du budget ?

Envoyer un blob via com.atproto.repo.uploadBlob coûte zéro point, car ce n'est pas une écriture d'enregistrement. Une publication avec quatre images coûte 3 points pour l'enregistrement du post et ajoute quatre requêtes HTTP de plus, une par image, cinq requêtes au total. Le budget de points ne compte que les CREATE, UPDATE et DELETE sur les enregistrements, pas les envois de blobs.

Que signifie vraiment l'en-tête ratelimit-reset ?

ratelimit-reset est un horodatage Unix qui indique quand la fenêtre en cours se termine, pas un nombre de secondes à attendre. Une réponse de com.atproto.server.describeServer le 10 septembre 2026 a renvoyé ratelimit-reset: 1789052966 avec ratelimit-limit: 3000 et ratelimit-remaining: 2999. Il faut patienter jusqu'à ce moment-là plutôt que dormir ce nombre en secondes, et l'en-tête Retry-After de la spécification atproto reste un champ séparé et optionnel envoyé seulement avec un 429.

À quelle fréquence peut-on changer son handle Bluesky sans toucher une limite de taux ?

com.atproto.identity.updateHandle est plafonné à 10 changements par 5 minutes et 50 par jour, par compte. C'est bien plus strict que le plafond de 300 par jour de createSession, donc un script qui renomme des handles selon un calendrier atteint cette limite bien avant de toucher son budget d'écriture.