Bluesky API for posting and scheduling without rebuilding the AT Protocol stack

Developer-first products, open social platforms, and the brand teams they serve integrate Bluesky for text posts, images, alt text, link cards, post history, and comments where supported. It is not a conventional posting API with one central host: posts are records written to the personal data server the user chose, which may be operated by someone other than Bluesky.

bundle.social does that protocol work and exposes Bluesky through the same post endpoint as every other channel. Your backend can schedule posts, upload images, attach link cards, and track delivery status without implementing record writes and blob uploads directly.

Most social APIs accept a payload and return a post ID. Bluesky asks you to write a record into a repository hosted on the user's Personal Data Server, which may not be operated by Bluesky at all. Images are content-addressed blobs uploaded separately and then referenced. Link previews are embeds you assemble yourself. Nothing about this is harder than a container flow, but none of it maps onto a conventional post-and-forget integration.

The practical consequence is that a Bluesky failure can originate in a place no other platform has: the user's own PDS. If that server is down, slow, or rejecting writes, publishing fails for that user and works for everyone else, and no amount of correctness on your side changes it.

Because publishing is a write followed by propagation, an integration that reports success on request acceptance can be wrong. The blob upload can succeed while the record write fails, leaving orphaned media and no post. Propagation delays can make a successful write briefly invisible, which looks like a failure to a user refreshing their profile.

bundle.social confirms the record write rather than the request, and separates an invalid record or upload from a PDS outage. The first needs the payload changed, the second needs a retry once the user's server recovers.

Bluesky occupies the same content slot as X and Mastodon (short text, optional images, link cards), which makes it cheap to add to an existing text-first workflow and easy to get wrong by treating it as identical. The 300-character cap is stricter than X Premium's 25,000 and matches free-tier X, so copy written for one usually fits the other. The link card difference is the trap: text that renders with a rich preview on X renders bare on Bluesky unless the embed is built.