Skip to main content

​
Scheduled vs. native scheduling

Postbreeze does not rely on each platform’s native “schedule” endpoint. Instead, a scheduled post is held in the Postbreeze database until its scheduledAt time, then fanned out by a Temporal workflow to every target social account. Why: most platforms (TikTok, Threads, X) have flaky native scheduling support or none at all. Owning the queue lets Postbreeze surface consistent retry, partial-publish, and audit semantics across them all.

​
Lifecycle

A Post walks through these statuses:
  • DRAFT — created with no scheduledAt. The API call returns immediately.
  • SCHEDULED — scheduledAt is set; a Temporal workflow is registered to fire at that time.
  • PUBLISHED — every target succeeded.
  • PARTIALLY_PUBLISHED — some targets succeeded, others failed.
  • FAILED — all targets failed, or a validation error occurred.
Each per-target outcome is recorded in PostTarget.status and a PublishAttempt audit row.

​
Time zones

scheduledAt is always UTC ISO-8601. The workspace’s timezone field is for display only — it doesn’t affect when the workflow fires. If you want to publish at “9am on Monday in New York”, convert client-side before submitting.

​
Cancellation

POST /posts/{id}/cancel (or the cancel_post MCP tool) terminates the Temporal workflow if it hasn’t fired yet, then flags the post as cancelled. Already-published targets stay published; only the unpublished ones are stopped.