Guides
Scheduling and approvals
How scheduledAt is interpreted, what pending means, and how a post gets through approval.
Scheduling
scheduledAtis ISO 8601 with a timezone. Send UTC (Z) to avoid surprises.- Omit it and the post is a draft. Set it later with
PATCH /posts/:idto schedule. - Up to five minutes in the past is moved to now with a
SCHEDULED_TIME_COERCEDwarning, so a script that computed the time before a slow upload does not fail. Earlier than that is refused withSCHEDULED_TIME_IN_PAST. POST /posts/:id/publishskips the queue and delivers now, waiting for the outcome.GET /best-timessuggests slots from the workspace's own history.
The approval rule
A scheduled post can be routed through review. Two things route it:
- The workspace setting
requirePostApproval. When it is on, every scheduled post created over the API lands aspending. This is a workspace-level setting the API honours; there is no self-serve toggle for it in the app today, so it is off unless overads has turned it on for your workspace. requireApproval: trueon the post itself, the same checkbox the composer shows. Use it when one post needs a second pair of eyes.
Either way the create call succeeds. The post has approvalStatus: "pending", and when the workspace rule caused it the response carries the warning:
{
"data": { "id": "…", "status": "scheduled", "approvalStatus": "pending" },
"warnings": [
{ "code": "APPROVAL_REQUIRED", "message": "This workspace requires approval for scheduled posts. The post is queued as pending and will not publish until a member approves it in the app." }
]
}What pending means
- The post is scheduled and visible in the app's approval queue, but the scheduler will not deliver it until it is
approved. POST /posts/:id/publishon a pending post is refused with409and codeAPPROVAL_REQUIRED. There is no API call that approves a post; a member does it in the app.- Editing a pending post is allowed. Scheduling a draft through
PATCHapplies the workspace rule the same way create does. post.approval_requiredfires when the post enters the queue andpost.approvedwhen a reviewer approves it, withapprovedBy. Subscribe to both to know when to expect delivery.
Over MCP the same warning rides on create_post and update_post. The server's instructions tell the model to say so and not retry; if you build your own agent, do the same.