Skip to main content
Studio runs its own scheduler rather than handing posts to a platform’s native one, so a single system knows what is pending.

Schedule it

The assistant calls schedule_post with an ISO 8601 timestamp that includes an offset:
Studio checks up front that the time is in the future, the target platform is connected, and the content fits that platform’s limit — you find out now, not at 2am when it fires.
Always send an offset (+02:00) or a Z. A bare local timestamp is ambiguous and will be rejected or land in the wrong hour.

Verify

list_posts with status: "scheduled" returns each post with its scheduledAt and the resolved scheduledPlatform.

Edit while it waits

Content edits are safe on a scheduled post — the new text is re-checked against the platform it is aimed at:
Changing which platforms it targets is draft-only. Unschedule first:

Move or cancel

When it fires

A cron tick runs every minute, so posts go out within roughly two minutes of the target time. Dispatch re-validates everything against the database, then publishes through the same path as publish_post. If it fails, the post lands in failed with a failureReason:
Permanent problems — a revoked connection, an expired token, a platform rejection — fail on the first attempt. Transient ones (rate limits, platform outages) retry with exponential backoff up to five times. Fix the cause, then re-schedule the failed post directly — no need to unschedule it first: