How to schedule Ghost posts and newsletters ahead of time

What Ghost and newsletter scheduling looks like in TimeToPost

TimeToPost treats scheduling like a simple handoff: you write the post, give it target accounts, optional media, and a future scheduledAt timestamp, then the background scheduler publishes it when that time arrives. The docs list Ghost publications and Buttondown newsletters as supported publishing targets, along with other connected accounts.

The key detail is boring in the best way, scheduledAt must be in the future. Past times are rejected, and a scheduled post moves through the lifecycle automatically. The API and scheduler do the bookkeeping so you do not have to babysit a tab like it owes you money.

Choose how you want to schedule: dashboard, API, or MCP

TimeToPost gives you three ways to create a scheduled post or draft.

1. Dashboard, for clicking through the composer yourself.
2. REST API, which uses the same backend as the web dashboard, so what you can click you can also script. The API reference says the web dashboard and API share the same request layer, and POST /api/posts accepts either specific connected account IDs or platforms.
3. MCP, for MCP-compatible clients and agent-assisted scheduling. The MCP page explains that the hosted server wraps the same REST API the web app uses, so an agent is still working under your account permissions, just with fewer mouse clicks and more feelings of inevitability.

If you want an agent to help set things up, MCP is the one to look at.

Schedule a Ghost post step by step

Here is the practical flow for a Ghost post in TimeToPost.

1. Write the content you want to publish.
2. Select the Ghost publication account you want to target.
3. Add optional media if the post needs it.
4. Set scheduledAt to a future ISO 8601 timestamp.
5. Save it as scheduled, not as a draft.

That last part matters. In TimeToPost, a draft is saved without a publish time, while a scheduled post has a future publish time and waits for the background scheduler to pick it up. If you set a past time, the request is rejected. If you need to stop it before it goes live, you can cancel the scheduled post before it fires.

For a Ghost publication, the important bit is the target account. Pick the connected Ghost account, then let the timestamp do the rest.

Schedule a Buttondown newsletter step by step

The workflow for a Buttondown newsletter is basically the same, because the scheduler does not care whether the target is a social account or a newsletter connection. It still wants content, the correct connected account, and a future publish time.

1. Draft the newsletter content.
2. Choose the Buttondown newsletter connection as the target account.
3. Add media only when your newsletter workflow requires it.
4. Assign scheduledAt a future ISO 8601 timestamp.
5. Save it in scheduled status.

Again, the publish time must be in the future. If it is not, TimeToPost rejects it instead of pretending everything is fine and then ghosting you, which is honestly refreshingly honest software behavior.

Worked example: schedule a Ghost post for Monday and a newsletter for Tuesday

Hypothetical example

Say you want to queue two items:

• A Ghost post for Monday at 2026-08-03T15:00:00.000Z
• A Buttondown newsletter for Tuesday at 2026-08-04T15:00:00.000Z

In TimeToPost, you would create each item with its own connected target account and its own future scheduledAt value. The Ghost post uses the Ghost publication connection, and the newsletter uses the Buttondown connection.

What you should see in TimeToPost is straightforward, both items appear with scheduled status. When each time arrives, the background scheduler publishes them automatically. That is the verifiable result to look for, scheduled first, published later, with no extra ritual required.

How to confirm the schedule and fix common mistakes

Check the posts list after saving. The REST API documents GET /api/posts, which returns posts with status values such as draft, scheduled, publishing, published, failed, and partial. In the dashboard, the same idea applies, drafts are unscheduled, scheduled posts are waiting for their publish time.

If something does not queue correctly, the usual suspects are pretty unglamorous:

• The timestamp is not a valid future ISO 8601 value.
• The timestamp is in the past, which TimeToPost rejects.
• You picked the wrong target account, so the post is aimed at a different connection than the one you meant.

When a scheduled post publishes, TimeToPost records a result per account. That matters when one post fans out to more than one connected destination, because each account can succeed or fail on its own.

When to use the API or MCP instead of the dashboard

Use the dashboard if you are scheduling one Ghost post or one newsletter and want to do it by hand.

Use the REST API if you want to schedule Ghost posts and Buttondown newsletters in bulk, wire scheduling into your own systems, or create posts from code. The API docs say it is the same API the dashboard uses, which makes it the practical choice when click-ops starts feeling like a hobby you did not sign up for.

Use MCP if you want an agent or another MCP-compatible client to handle the setup. The MCP page says the hosted server wraps the same REST API, so the capabilities stay inside TimeToPost’s documented behavior while your client does the typing.

If you are choosing between them, the simple rule is: dashboard for one-off work, API for automation, MCP for agent-assisted scheduling.