How to Cross-Post to Mastodon Automatically Without Registering a Developer App

TL;DR: Cross-posting to Mastodon automatically means sending a status to whichever server, or instance, your account actually lives on, since there’s no single company-run API the way there is for X. The official route runs through POST /api/v1/statuses after you register a developer app and generate an OAuth token, and every instance can set its own rate limits and character caps on top of that. Tools that drive the browser session you’re already logged into skip the app-registration step and post through the same endpoint your account already uses.

Pick a Mastodon server and you’re choosing more than a username. mastodon.social runs the platform’s default rate limits and a 500-character post cap, but hachyderm.io or fosstodon.org can set entirely different ones, because as joinmastodon.org puts it, “Mastodon is not a single website.” It’s thousands of independently operated servers that happen to talk to the same protocol. That’s the part a script built for X or LinkedIn gets wrong on its first pass: there’s no single mastodon.com endpoint to call, just whichever instance your account happens to be registered on.

If you’re already posting to X, Threads, or Bluesky and adding Mastodon as a fourth leg, the instance question is usually what breaks first. Point a tool at the wrong domain and the post either fails outright or gets throttled by a rate limit you didn’t know your specific server had set.

Why Mastodon automation has one extra step X and Threads don’t

Officially posting to Mastodon means registering an application first. You send a POST /api/v1/apps request and get back a client_id and client_secret, then trade those for an access token through /oauth/token, either with a client-credentials grant or the full user-authorization flow, per Mastodon’s own client-token documentation. Compare that to Threads, where the barrier is a single Meta App Review queue, or X, which gates access by pricing tier. Mastodon has no review queue at all, but it also has no single developer console. Every instance is its own registration target.

The rate limits stack on top of that. Mastodon’s own rate-limits documentation sets the default at 300 requests per 5-minute window, with tighter caps of 30 calls per 30 minutes on media uploads and status deletions. Any instance admin can move that default up or down, so the limit that actually applies to your account depends on where you signed up, not on one universal Mastodon rule. The same goes for the post length itself: the platform ships a 500-character default, but Mastodon’s posting documentation is explicit that any instance can raise it, and some run limits into the thousands.

None of this is a wall exactly, since there’s no approval process to wait on. It’s more like a scavenger hunt: the actual constraints on your account live on your instance’s settings page, not in a single API reference everyone reads once.

Let an AI post through the session you already have

This is where PublishPort’s opencli-based Mastodon adapter (currently pinned at publishport-opencli@1.0.19) skips the app-registration dance above entirely. Instead of walking through POST /api/v1/apps and managing a client_id and client_secret yourself, it reads the access token straight out of the browser tab you’re already logged into. Mastodon’s own web app stores that token in a page-level “initial state” object the moment you sign in, and the adapter reads it from there rather than asking for a separate credential. That means an AI calling the publish command through PublishPort’s local_bash tool posts with the exact same access your browser session already has, on whichever instance you point it at with --site, not hardcoded to mastodon.social.

It’s the same session-based approach behind cross-posting to X, Threads, Bluesky, and Mastodon in one comparison, narrowed here to this one platform, and it works the same way the Bluesky adapter handles AT Protocol’s XRPC calls: no separate app credential to generate or rotate. The free desktop client is what an AI agent connects to before it can call that publish command at all.

How to actually set it up

1. Install the PublishPort desktop client and let it detect your machine’s logged-in browser profiles.
2. Log into your Mastodon instance normally, in the same browser the client will use, so the session token is already there when the adapter reads it.
3. Connect your AI agent through the client’s MCP endpoint, then have it call list_capabilities() and confirm Mastodon shows up as postable.
4. Tell the agent which instance to use if you run more than one account, since the adapter needs a --site value rather than assuming a default server.
5. Check the first few posts against your instance’s own character limit and visibility settings before handing over anything time-sensitive.

Content warnings and the bot flag: etiquette other platforms don’t have

Two things about Mastodon culture matter more here than on X or Threads, and an automated posting setup needs to respect both. First, content warnings: Mastodon supports a spoiler_text field that collapses a post behind a click-to-reveal label, and setting one automatically marks any attached media as sensitive too. It’s a widely used community convention for spoilers, sensitive topics, and even just long threads, not an edge case to bolt on later.

Second, the automated-account flag. Mastodon lets any account owner mark their own profile as automated from Edit Profile, which adds a visible bot icon so followers know a human might not be reading replies right away. Only the account owner can set it, nobody else can flag your account this way. It matters because some servers specifically discourage what fedi.tips calls “zombie accounts”: accounts that post on autopilot and never engage with anything that comes back. Flipping the automated flag is a one-click courtesy that costs nothing and tells the truth about how the account runs.

Limits and what to keep in mind

Automating the publish step doesn’t change what your instance’s rules allow. Rate limits apply the same whether a script or a person is calling the API, and an instance that bans “substantially similar content across servers” or requires manual approval for new accounts will enforce that regardless of who’s posting. If you’re running accounts on more than one instance, treat each as a fully separate login and rate-limit budget, not one account with several names. And because the session token functions like a password, keep the machine running your AI agent, and the credential connecting it, as carefully guarded as you would any other login.

Mastodon cross-posting checklist

• Confirm which instance your account actually lives on, and check that instance’s real rate limit and character cap instead of assuming the 500-character default.
• Decide whether you need the full developer OAuth flow for a standalone tool, or can post through your own already-logged-in session instead.
• Use content warnings the way your instance’s culture expects, not only when a filter forces one.
• Flip on the automated-account flag if the posting won’t be monitored in real time.
• Keep the same posting pace you’d use by hand. No bulk blasts, no duplicate content across every instance you’re on.

FAQ

Does Mastodon have an official API for posting?

Yes. Mastodon exposes a public REST API, and posting a status goes through POST /api/v1/statuses once you have a valid access token. There’s no approval queue to clear, but you do need to register an application and complete an OAuth flow first, per Mastodon’s own client documentation.

Do I need to register a developer app to post to Mastodon?

Only if you’re calling the API directly with your own code. That means a POST /api/v1/apps request for a client ID and secret, then an OAuth token exchange. Tools that drive your existing logged-in browser session skip this step because they read the token your session already holds instead of requesting a new one.

What are Mastodon’s rate limits?

The platform default is 300 requests per 5-minute window, with media uploads and status deletions capped tighter at 30 per 30 minutes. Individual instance admins can adjust these defaults, so the limit that applies to your account depends on which server you signed up on.

Will automating Mastodon posts get my account flagged as a bot?

Automation itself isn’t the trigger. Posting on autopilot and never replying to anything is what some instances discourage as a “zombie account.” Marking your profile as automated in your settings is the honest way to signal that, and it’s a setting only you can turn on for your own account.

Can one tool post to multiple Mastodon instances at once?

Yes, as long as it treats each instance as a separate login and rate-limit budget rather than one shared account. A tool that hardcodes mastodon.social as the only target won’t reach an account registered anywhere else.

Does every Mastodon server have the same character limit?

No. The platform ships a 500-character default, but any instance admin can raise it, and some run limits well into the thousands. Check your specific server’s settings rather than assuming 500 everywhere.