Understand the post lifecycle
Map drafts, reviews, schedules, dispatch, partial success, failure, and cancellation correctly.
A post moves through draft, in_review, approved, scheduled, queued, processing, partially_succeeded, succeeded, failed, or canceled. Each target account also carries its own delivery state, attempts, remote identifiers, billing state, and errors.
What this means in practice
A post moves through draft, in_review, approved, scheduled, queued, processing, partially_succeeded, succeeded, failed, or canceled. Each target account also carries its own delivery state, attempts, remote identifiers, billing state, and errors.
Use the documented brand and account boundaries consistently across the scheduler, REST API, SDK, MCP tools, SSE consumers, and webhooks. That makes the same social operation explainable to an operator and reproducible by an integration.
Implementation checklist
Render the parent state as a workflow summary, not a replacement for target details.
Use in_review and approved only when the brand's approval policy requires them.
Treat queued and processing as non-final states.
Show partial success whenever at least one target succeeds and another does not.
Preserve terminal results and audit history after cancel, retry, or reconciliation.
Operational details
Targets can include billing_blocked even while the requested schedule remains preserved.
Provider callbacks or reconciliation can move an earlier ambiguous attempt to a later confirmed result.
Cancel prevents future work where possible but cannot guarantee deletion of an already-published remote post.
Common mistakes to avoid
- Do not show processing as a green published state.
- Do not collapse partial success into failed and hide successful remote posts.
- Do not discard attempt history when a retry begins.