How to auto-generate blog posts with human approval
TL;DR: Use TimeToPost as a draft-first pipeline: AI creates drafts, a human reviews them, and approval moves the post into scheduling. Use MCP `create_drafts` for agent-generated drafts or `POST /api/posts` without `scheduledAt` for REST drafts, then approve, reject, and schedule only after review.
Use a human-in-the-loop draft pipeline, not fully automatic publishing
Set the workflow up so AI creates the draft, a person reviews it, and only approved drafts get scheduled or published. That is the boring-but-safe version, which is usually the one that survives contact with reality.
The basic rule is simple: draft first, human check second, publish later.
Pick the approval path that matches the content source
TimeToPost gives you two documented entry points for this workflow.
If an AI agent is creating the post, use create_drafts through MCP. Those drafts always wait for human approval, so you do not need to bolt on a separate “please do not publish yet” layer. The agent can write, but it cannot skip the handoff.
If you are using the REST API directly, POST /api/posts can save a draft when you omit scheduledAt. The same endpoint also supports future scheduling, but for an approval flow, the draft path is the one you want.
A useful split is this, MCP for agent-generated drafts, REST for systems that already know how to send JSON.
Build the approval gate around TimeToPost’s native tools
The minimum loop is already in the docs, so there is no need for a clever Rube Goldberg machine.
list_draftsto see what is waiting.- Review the content.
approve_draftif it passes.reject_draftif it does not.- After approval, schedule it for a future time.
If you need status checks during the handoff, list_drafts, approve_draft, and reject_draft are the key tools. TimeToPost also documents list_posts on MCP and GET /api/posts in the REST API, so you can verify what ended up scheduled or published without guessing.
At the REST layer, the post lifecycle is straightforward: a draft saved without a publish time does not publish on its own, and a future scheduledAt moves it into scheduled state.
Worked example: from AI draft to approved scheduled post
Hypothetical example time, because made-up examples are easier to reason about than production mess.
An AI agent drafts a social post for a product launch:
"Launch day is here. The new guide is live, the checklist is updated, and the team has officially earned coffee."
A reviewer checks three things before approving it, brand voice, factual accuracy, and whether the timing makes sense for the audience. The reviewer notices that the draft is fine, but it should go out tomorrow morning instead of late tonight.
The draft is approved, then scheduled with a future ISO 8601 timestamp such as 2026-07-01T15:00:00.000Z. TimeToPost’s API requires scheduledAt to be in the future, and it rejects past times.
Verifiable result, the approved draft becomes scheduled. If the reviewer rejects it instead, it does not go live. That is the whole point of the gate.
What the human reviewer should verify before approving
Keep the review tight and focused on the approval problem.
Check that the content is accurate. Check that it targets the right account or accounts. Check that any media is ready and attached correctly. Check that the scheduled time is in the future.
That last one matters because the REST API rejects past scheduledAt values. If the reviewer sees a timestamp that has already come and gone, it should be fixed before approval, not after the scheduler has had a chance to complain.
If the post is meant for several accounts, also confirm the targets are the ones you actually meant to hit. Nothing ruins a clean approval flow faster than posting the right thing to the wrong place.
Use the approval result to trigger the next step
Approval is not the finish line, it is the handoff into scheduling.
That lets you automate notifications, ticket updates, or internal logging without removing the human decision from the loop.
In other words, the person stays in charge, and the systems do the tedious parts after the decision is made. Good deal for everyone except unnecessary busywork.
Where TimeToPost fits if the article is part of a migration away from another scheduler
If this approval workflow is part of a migration, start with the migration checklist article so you can export posts, drafts, media URLs, and account mappings before you switch. That gives you the plumbing you need before you rebuild the approval flow in the new setup.
Once the data is mapped, connect the new draft-and-approve workflow to TimeToPost and move the content over cleanly instead of trying to improvise on publish day.
Relevant setup and reference pages
For agent-based drafting, see MCP setup. It is the right entry point when an AI assistant is creating drafts and a human is approving them.
If you are still mapping the broader workflow, the use cases page is a decent orienting stop without sending you into the weeds.