Schedule Bluesky posts across every account your product or your team publishes for, with blob uploads, link cards, and the 300-character cap handled per account regardless of which server hosts it.
Last updated: July 2026
One API key. No per-account fees. 15 platforms.
1await fetch("https://api.bundle.social/api/v1/post", {2 method: "POST",3 headers: {4 "x-api-key": process.env.BUNDLE_SOCIAL_API_KEY,5 "Content-Type": "application/json"6 },7 body: JSON.stringify({8 teamId: "team_123",9 title: "Bluesky campaign",10 postDate: "2026-05-14T10:00:00.000Z",11 status: "SCHEDULED",12 socialAccountTypes: ["BLUESKY"],13 data: {14 BLUESKY: { text: "Scheduled from bundle.social." }15 }16 })17});Your developer audience moved to Bluesky for a reason. Give them content on their terms without building a custom AT Protocol client just to send a scheduled post.
Workflow
Connect accounts once, then create and schedule posts with channel-specific fields from one API.
Generate an organization API key in the dashboard and use it with the x-api-key header.
Connect each social account once. bundle.social keeps the account mapping ready for future posts.
Bluesky posts are records written to the user's PDS, with images uploaded as blobs and link cards built as embeds. You send one request; bundle.social uploads the blobs, builds the embed, and confirms the record write.
Product architecture
Developer-first products and the brand teams they serve rarely adopt Bluesky alone. It arrives with X, Mastodon, and Threads as part of a text-first plan built on short posts, images, alt text, and link cards.
bundle.social schedules Bluesky in the same calendar as those channels. Draft posts, attach images with alt text, schedule them with the rest of a campaign, and follow delivery status without dealing with protocol details.
Bluesky posts are capped at 300 characters, and the audience expects a different register from LinkedIn or a company blog. Copying one message across every text channel is fast and usually reads as automation, which is the opposite of what an open social audience responds to.
Per-channel copy lives inside one scheduled campaign, so a Bluesky post can differ from its X and Mastodon siblings while staying part of the same plan. Length validation follows the rule the protocol applies, so posts are checked before they are scheduled rather than after they fail.
Open social channels are usually adopted together, and teams need to know whether the audience there behaves like the audience on X. That comparison only works when the posts, timing, and results sit in the same view.
bundle.social puts Bluesky scheduling, approvals, post history, and analytics where the platform and account expose them next to every other channel. Bluesky and AT Protocol behavior can evolve quickly, so those details stay in one integration layer rather than in your calendar workflow.
A Bluesky account can live on a Personal Data Server that Bluesky does not operate, so the connection is to the user's own host rather than to one central API.
You generate a hosted portal link, your user connects their own Bluesky account through it, and bundle.social stores and refreshes the token. The link carries your branding, expires on a window you set between 5 minutes and 48 hours, and means you never implement Bluesky AT Protocol OAuth yourself. Publishing from your own code instead of the dashboard uses the same connected accounts.
Capabilities
Bluesky fits into the same scheduling, media, and status workflow as every other channel.
Plan and schedule Bluesky content alongside Instagram, LinkedIn, X, TikTok, and every other channel without switching between native dashboards.
Bluesky content still uses the options and fields the platform supports. No generic template that loses native capabilities.
Marketing teams can draft, review, and approve Bluesky content in the shared calendar before anything publishes.
Upload visuals, videos, and documents once and attach them to Bluesky posts using upload IDs across your content plan.
See whether each Bluesky post is scheduled, processing, posted, or failed without checking the native platform dashboard.
Pull Bluesky performance data and import post history for connected accounts where the platform API and permissions allow it.
Developer example
Examples use bundle.social's public API shape: API key authentication, a post date, selected social account types, and platform-specific data.
1await fetch("https://api.bundle.social/api/v1/post", {2 method: "POST",3 headers: {4 "x-api-key": process.env.BUNDLE_SOCIAL_API_KEY,5 "Content-Type": "application/json"6 },7 body: JSON.stringify({8 teamId: "team_123",9 title: "Bluesky campaign",10 postDate: "2026-05-14T10:00:00.000Z",11 status: "SCHEDULED",12 socialAccountTypes: ["BLUESKY"],13 data: {14 BLUESKY: { text: "Scheduled from bundle.social." }15 }16 })17});Guarantees
Track scheduled, processing, posted, retrying, and error states per post.
When native APIs fail, we return human-readable error messages and actionable recovery steps.
No per-post counting. Predictable pricing for teams managing many users, workspaces, and connected accounts.
Direct access to the engineers building the API. We respond to technical issues the same day, sometimes the same hour.
FAQ
Because Bluesky posts are records written to the user's Personal Data Server, and that server is not necessarily operated by Bluesky. If a user's host is down or rejecting writes, publishing fails for that user only. Nothing on your side is wrong and no retry aimed at your own service helps.
Bluesky does not build a preview from a URL in the text. The card is an embed you construct, with a title, a description, and a thumbnail uploaded as its own blob. Content cross-posted from X or Mastodon without that step renders as a bare link.
When the record write is confirmed, not when the request is accepted. A blob upload can succeed while the record write fails, leaving orphaned media and no post, and propagation delay can make a successful write briefly invisible. bundle.social confirms the write rather than the request.
Because a conventional client stops at the request. Publishing means uploading blobs, writing a record to a server the user chose and Bluesky may not operate, and constructing link cards yourself. bundle.social confirms the record write rather than the request, builds the embed so links do not render bare, and tells a bad record apart from the user's own host being down.
Yes. You generate a hosted portal link carrying your own branding, and bundle.social stores and refreshes the Bluesky token, so a reconnect is something your user can do without a support ticket.
Yes, and the per-platform differences stay per platform. One scheduled post can target several channels at once, with a BLUESKY object carrying only the fields Bluesky needs.