Key takeaways
- Repo-record writes (posts, likes, follows, reposts, and more) share one points budget per account: 5,000 points/hour and 35,000 points/day.
- A CREATE (a new post) costs 3 points, an UPDATE costs 2, a DELETE costs 1 — so a posting-only account could sustain roughly 1,666 creates/hour or about 11,666/day before hitting the ceiling, IF nothing else on the account (likes, follows, reposts) draws from the same shared budget.
- createSession (login) is limited separately: 30 calls per 5 minutes and 300 per day, per account.
- An aggressive scheduling cadence of one post every 5 minutes uses only about 0.7% of the hourly write budget and 2.5% of the daily one — normal scheduling-app usage will never approach Bluesky's write ceiling.
Bluesky API rate limits: the points budget
Bluesky's official rate-limits documentation sets a shared write-points budget per account: 5,000 points per hour and 35,000 points per day. Every repo-record write draws from this same pool, not just posts — likes, follows, and reposts all count too. Within that budget, a CREATE (making a new record, such as a post) costs 3 points, an UPDATE costs 2 points, and a DELETE costs 1 point.
Working the ceiling backward: if an account's activity were posting-only, with nothing else consuming the shared budget, the hourly points cap allows up to roughly 1,666 creates, and the daily cap allows roughly 11,666. In practice any real account also likes and follows, which eats into the same budget — so those numbers are theoretical ceilings, not a safe target.
Authentication has its own, separate limit
createSession — logging in — is rate-limited independently of the write-points budget: 30 calls per 5 minutes and 300 per day, per account. A service that re-authenticates aggressively (for example, creating a fresh session on every job run instead of reusing and refreshing an existing one) is far more likely to hit this ceiling than the write-points budget.
What this means in practice for a scheduling app
A realistic scheduling cadence sits nowhere near either ceiling. Posting once every 5 minutes around the clock is 12 posts/hour and 288 posts/day — at 3 points per post, that consumes 36 of the 5,000 hourly points (about 0.7%) and 864 of the 35,000 daily points (about 2.5%). Even a considerably more aggressive cadence would stay well under Bluesky's write budget; the practical risk in production is re-authenticating too often against createSession's tighter, separate limit, not exhausting the write-points pool.
FAQ
- Does Bluesky rate-limit by requests per minute, like most other social APIs?
- No — Bluesky uses a points-based budget for repo-record writes (5,000 points/hour, 35,000/day), where different write operations cost different amounts of points, rather than a flat count of requests per time window.
- How many points does creating a Bluesky post cost?
- A CREATE operation (which a new post is) costs 3 points; an UPDATE costs 2 and a DELETE costs 1, all drawn from the same shared per-account budget.
- How many posts per hour can a Bluesky account realistically sustain?
- The theoretical ceiling is roughly 1,666 posts/hour if a post is the ONLY write activity on the account — but a normal scheduling cadence (for example, one post every 5 minutes) uses under 1% of that hourly budget, so posting volume is essentially never the limiting factor.
- Is Bluesky's login (createSession) rate-limited separately from posting?
- Yes — createSession has its own limit of 30 calls per 5 minutes and 300 per day, per account, entirely separate from the write-points budget that governs posts, likes, follows and reposts.
- Do likes and follows count against the same limit as posts?
- Yes — all repo-record writes (posts, likes, follows, reposts, and more) draw from the same shared points budget on an account, so heavy liking or following activity reduces how many points remain for posting.
- What is the most likely rate-limit problem a scheduling app will actually hit on Bluesky?
- Re-authenticating too frequently against the separate createSession limit, rather than exhausting the write-points budget — a service that creates a fresh session on every run instead of reusing and refreshing one is the more realistic risk.