How to Schedule Mastodon Posts: The Built-In Scheduler Mastodon Never Shows You

Short answer: yes, you can schedule Mastodon posts, and Mastodon has supported it at the API level for years. What almost nobody tells you is that the official web client and the official mobile apps never expose it. Open Mastodon.social in a browser or the app store version on your phone and there is no "schedule" button anywhere near the compose box. The feature exists. It just lives one layer below the interface most people use.

This is the definitive guide to actually scheduling Mastodon posts in 2026: the native scheduled_at field, what you need to call it yourself, the third-party tools built on top of it, and where a calendar workflow like TimeToPost fits if you post to Mastodon alongside everything else.

The hidden native scheduler

Mastodon's REST API accepts a scheduled_at parameter on the same endpoint you use to publish a normal post: POST /api/v1/statuses. Set it to an ISO 8601 timestamp at least 5 minutes in the future, and instead of publishing immediately, the server holds the post and fires it for you at that time.

The response you get back is not a regular Status object either. It is a ScheduledStatus, with its own ID and its own endpoints (GET /api/v1/scheduled_statuses, PUT, and DELETE to edit or cancel a pending post before it goes out). Mastodon built a real scheduling system into the protocol itself, server-side, no third party required.

So why doesn't the app show it? Nobody at Mastodon has published a definitive reason, but the practical effect is the same everywhere: the compose UI in the official web client and the official iOS and Android apps has no time picker for it. If you want it, you either call the API directly or use a tool that does.

What you need

• A Mastodon account on any instance that runs a reasonably current version of the software. Scheduling has been part of the API for a long time, so this covers nearly every active server.
• A registered application on that instance. Mastodon's OAuth is per-instance: there is no single global app registry the way there is with, say, X or Meta. You register once per server via POST /api/v1/apps, which gives you a client_id and client_secret scoped to that instance only.
• An OAuth access token with the write:statuses scope, obtained through the normal OAuth authorization flow (or, for personal scripts, an access token generated directly from your account's Development settings).
• Your instance's base URL, since every request is https://your-instance.example/api/v1/.... If you ever move instances, none of this carries over automatically.

Method 1: API scheduling, direct

For a single account, this is the whole thing:

POST https://your-instance.example/api/v1/statuses
Authorization: Bearer <access-token>

status=Your post text here
scheduled_at=2026-07-20T14:30:00Z

That returns a ScheduledStatus with an id and the scheduled_at you sent back to you for confirmation. To see what's still queued, call GET /api/v1/scheduled_statuses. To pull a post before it fires, DELETE /api/v1/scheduled_statuses/:id. There is no bulk endpoint: each scheduled post is its own call, so if you want to queue a week of content you are writing a small loop, not clicking through a calendar.

This is genuinely the simplest native scheduling API of any major platform covered in this series. One field, one endpoint, done. The catch is entirely on the client side: you need something making that call at setup time, because the official apps won't do it for you.

Method 2: scheduler tools

Because the official clients skip this feature, a handful of third-party Mastodon apps and web clients added their own scheduling UI on top of the same scheduled_at field. If you only post to Mastodon and nowhere else, a dedicated Mastodon-only client with a calendar view is a reasonable choice, and it is talking to the exact same API endpoint described above. There is nothing more powerful happening under the hood, just a UI Mastodon itself chose not to ship.

The tradeoff shows up the moment you post to more than one place. Mastodon-only tools mean a separate login, a separate content calendar, and a separate character counter for every other platform you run, which is exactly the coordination cost a multi-platform calendar exists to remove.

Method 3: a full calendar workflow with TimeToPost

TimeToPost doesn't have a one-click Mastodon connector yet. What it gives you today is the workflow layer around the API calls above: a shared content calendar where a Mastodon post sits next to your X, Instagram, and TikTok posts for the same launch or announcement, a character counter so you're not guessing whether a post fits Mastodon's default limit before you paste it into a client, and best-time-to-post data pulled from your other connected platforms so you're not scheduling Mastodon in a vacuum.

The practical setup looks like this: draft and time your Mastodon post inside TimeToPost's social media scheduler alongside the rest of your week, then fire it through your registered app's scheduled_at call, or a Mastodon client that supports it, at the moment your calendar says to post. It's not the single click you get with a platform TimeToPost has a live connector for, but it collapses the actual planning work, which is where most of the time goes anyway.

Limits: 500 characters default, media caps, rate limits

• Character limit. Mastodon's default is 500 characters per post. This is not a protocol-wide hard rule, though: it is a per-instance setting, and some servers raise or lower it. Check your specific instance before assuming 500 is your ceiling.
• Media caps. A single post supports up to 4 images, 16MB each, or one video or audio attachment up to 99MB. Mixing images and video in the same post isn't allowed.
• Rate limits. The API allows roughly 300 requests per 5 minutes per account and per IP address. Media uploads have their own tighter ceiling: about 30 uploads per 30 minutes. For scheduling a normal posting cadence, both of these are generous. They start to matter if you're backfilling a large queue in one script run.
• OAuth is per-instance, worth repeating here because it changes your setup checklist: an app registration and token on one Mastodon server does nothing on another. If you manage multiple accounts across different instances, you're registering and authorizing separately on each one.

Best time on a federated network (honest take)

Every "best time to post" claim you'll read for Mastodon should be treated with more suspicion than the equivalent claim for X or Instagram, and here's why: Mastodon is federated. Your followers are spread across potentially hundreds of independently run instances, each with its own timezone mix, its own local culture, and its own moderation and boost patterns. There is no single global algorithm deciding who sees your post and when, the way there is on a centralized platform, so there's no equivalent of a platform-wide engagement study to lean on.

What actually works is the same principle behind our general best-time-to-post research: track when your own posts get replies and boosts, and repeat what worked for your specific audience. On a federated network more than anywhere else, your account's own history is the only dataset that means anything.

FAQ

Why don't the official Mastodon apps show a scheduling option if the API supports it? The feature has been in the API for years, but the official web client and mobile apps have never added a compose-time picker for it. There's no published reason. If you want to use it, you call the API directly or use a client that built its own UI on top of it.

Does scheduling work on my instance? Almost certainly, since scheduled_at is a core part of the Mastodon API rather than an optional extra. What can differ per instance is the character limit and any custom rate limiting an admin has layered on top, so it's worth a quick check of your specific server's settings.

What's the actual character limit? 500 characters by default. It's a server-level setting, not a fixed protocol rule, so some instances allow more and some allow less. Confirm on your instance rather than assuming.

How far in advance can I schedule a post? The API requires at least 5 minutes in the future. There's no documented maximum, so long-range scheduling is a matter of what your client or script allows, not a Mastodon-imposed ceiling.

Can I edit a scheduled post before it goes out? Yes. PUT /api/v1/scheduled_statuses/:id lets you change the scheduled time, and DELETE on the same endpoint cancels it outright, both before it publishes.

If you're coordinating Mastodon with the rest of your platforms, our pricing page covers where that calendar workflow fits.