A Mastodon scheduler built for how federation actually works
Mastodon has no single API to post through — your account lives on one instance, and that instance is what WDIBoard connects to. Schedule posts and threads, preview formatting per network, and handle replies and mentions from one inbox, across as many instances as you run accounts on.
The problem: most schedulers assume one API, and Mastodon doesn't have one
Tools built for centralized networks connect once, to one endpoint, and every account they manage on that network flows through it. Mastodon doesn't work that way. It's a protocol, not a platform — thousands of independently run instances, each with its own domain, its own API endpoint, and its own users. There's no "Mastodon API" in the singular sense that there's a Facebook Graph API or a LinkedIn API. A scheduler that treats Mastodon like every other network either breaks or quietly only supports one instance, which is a real limitation for anyone running accounts on more than one.
If you post from an account on mastodon.social, another on a smaller topic-specific instance, and maybe a third somewhere else, that's three separate authorizations, three separate connections, and — done properly — three separately connected channels in your calendar.
Connect the specific instance your account lives on
When you add a Mastodon channel in WDIBoard, you authorize it against the instance that account actually runs on — not a generic "Mastodon" connection. That's not a workaround; it's the only way to connect to Mastodon correctly, because authorization happens at the instance level under the ActivityPub-based federation model the network runs on. WDIBoard handles that per-instance connection cleanly, so from your side it looks like connecting any other channel: authorize once, and it's in your calendar.
Multiple instances, no extra cost
Connected channels are unlimited on every WDIBoard plan, including Free — there's no cap in the pricing structure on how many you connect, and no per-channel fee. That matters more for Mastodon than for most networks, because running multiple instance-based accounts isn't an edge case here, it's normal. Connect an account on one instance and an account on a different instance, and both sit in the same calendar as separately connected channels, scheduled and managed together.
Thread building
Mastodon is one of four networks in WDIBoard where the composer supports building a thread directly — alongside X, LinkedIn and Bluesky. You write the full sequence as one unit in the composer rather than posting, waiting, and replying to your own post to continue it. The thread publishes in the order you built it.
Per-network preview
Because character limits, link handling and formatting vary by network, the composer shows a live preview scoped to Mastodon specifically, so what you see before scheduling is what actually publishes to that instance — not a generic composer view that assumes Mastodon behaves like something else.
Replies and mentions in the unified inbox
Replies and mentions on your connected Mastodon accounts land in the same unified inbox as every other network you've connected — with assignment, tags, saved replies and sentiment labels. If you're running accounts on two or three instances, that's one inbox for all of them instead of three separate apps or browser tabs to check.
Analytics
Mastodon activity feeds into your analytics dashboards alongside every other connected channel — follower growth, engagement, reach and impressions, best-time heatmaps and top posts — so an instance-based account isn't a blind spot next to the mainstream networks you're also tracking.
What federation actually means for a scheduling tool
This is worth stating precisely, because "federated" gets used loosely. There is no central Mastodon company running one API that every account authenticates against. Each instance is independently operated software, and your account's identity, posts and OAuth authorization all belong to that one instance. The practical consequences for scheduling:
| What you might assume | What's actually true |
|---|---|
| There's one Mastodon API to connect to, like Facebook or LinkedIn | Each instance runs its own API endpoint; there's no shared, cross-instance API to post through |
| Connecting "Mastodon" once covers every account you have on it | Each account, on each instance, is authorized and connected separately |
| A second account on a different instance is a minor variation of the first | It's a fully separate connected channel — different domain, different API endpoint, different authorization |
| A second account on the same instance as the first is somehow "linked" | Still a separate channel; instances don't share sessions between accounts either |
None of this is a complaint about Mastodon — it's the tradeoff federation makes deliberately, and it's exactly why several mainstream scheduling tools skip Mastodon rather than build per-instance connection handling. WDIBoard does the per-instance work so connecting an account is straightforward on your side, whichever instance it happens to live on.
Who this is for
Anyone running more than one Mastodon account. If your accounts sit on different instances — a general-purpose one and a topic-specific one, for example — connecting and scheduling both from one calendar is the whole point.
Developer and technical brands. Mastodon's audience skews technical, and a tool that gets the federation model right instead of hand-waving it tends to earn more trust with that audience than one that doesn't.
Agencies managing fediverse presence for clients. Per-instance connections, a unified inbox and unlimited connected channels mean a client with accounts on two instances doesn't cost more or take more tooling than a client with one.
Frequently asked questions
Can I schedule posts to Mastodon?
Yes. WDIBoard connects to the specific instance your Mastodon account lives on and schedules posts to it through the same calendar you use for the other nine networks it supports.
Can I connect Mastodon accounts on more than one instance?
Yes. Each Mastodon account is connected per instance, and connected channels are unlimited on every plan, so accounts on different instances all sit in the same calendar as separate channels.
Why do I have to connect Mastodon per instance instead of once?
Because that's how Mastodon works — there's no central API shared across instances. Each instance runs independently, and your account's authorization belongs to the specific instance it's on, so each one is a separate connection.
Does WDIBoard support Mastodon threads?
Yes. Mastodon is one of four networks — alongside X, LinkedIn and Bluesky — where the composer builds a thread as one unit that publishes in order, rather than requiring you to reply to your own post manually.
Do Mastodon replies and mentions show up anywhere besides the app itself?
Yes. Replies and mentions on your connected Mastodon accounts route into WDIBoard's unified inbox alongside every other connected network, with assignment, tags and saved replies.
Is Mastodon included on the Free plan?
Yes. Mastodon is one of the nine networks included on Free. All 10 networks, including X, are available from the Creator plan up, with no per-network add-on fee on any paid plan.
Can I see analytics for my Mastodon accounts?
Yes. Mastodon activity feeds into the same analytics dashboards as every other connected channel — follower growth, engagement, reach, impressions and top posts.
Connect your Mastodon accounts, wherever their instances live
Add each instance separately, build a thread, and see replies land in one inbox alongside your other channels.
Get early access