Mastodon API for posting and scheduling without managing instance-by-instance auth

Open-source products, developer tools, and the community teams around them use a Mastodon API for text posts, images, videos, links, alt text, polls, visibility levels, and scheduling. Mastodon is not one API but the same API implemented by thousands of independently operated servers, each with its own rules, rate limits, and account requirements.

bundle.social absorbs that federation work. Your product connects an account on whichever instance the user belongs to, then schedules posts, attaches media, and tracks status through the same workflow used for Bluesky, LinkedIn, X, and other text-first channels.

Integrating Mastodon is unlike integrating a centralized platform in one decisive way: there is no single host, no single developer account, and no single set of limits. Each user connects from their own instance, which is operated by someone else, configured differently, rate-limited differently, and running a different version of the software. Your integration talks to as many API endpoints as you have instances.

This changes what "working" means. A request that succeeds for a user on one server can fail for a user on the next because that instance sets a lower character cap, disables a media type, runs stricter rate limits, or is simply having an outage. Correctness is per-instance, which is why bundle.social reports instance-specific rejections as instance-specific rather than as a fault in the request.

Building Mastodon support means registering an OAuth application dynamically on each instance the first time a user connects from it, storing the resulting credentials per instance, and handling servers that block registration or go offline between connection and publish. There is no equivalent of a Meta app review to pass, but there is also no single set of credentials to manage. The operational cost moves from approval to multiplicity.

bundle.social handles the registration and credential storage per instance, so adding Mastodon to a product is a single API integration rather than an open-ended set of them.

Mastodon users expect alt text on images, content warnings on sensitive material, and visibility chosen deliberately rather than defaulted to public. None of it is enforced by the API, and all of it affects how content is received. Automated cross-posting without those signals reads as spam to this audience in a way it does not on Instagram or X. A product that schedules Mastodon content should expose alt text and visibility as normal fields, not advanced options.