"Posting" suggests a single fire-and-forget call. PostGate models it as what it actually is: content moves from draft or scheduled, through per-target delivery, to a terminal outcome — published, partial, or failed. Call it a social media posting API, a content publishing API, or an autoposting API — underneath, one POST /api/posts call and a structured delivery lifecycle is what backs all of them.
draft: true saves a post for approval before anything goes out. An ISO 8601 scheduled_at publishes at a fixed instant. scheduled_at: "queue" drops it into the next open recurring slot from a cron or slot schedule. Omit all three and delivery starts immediately.
Each platform target moves through pending, media_ready, publishing, and sometimes reconciling or retry_scheduled, before landing on published, failed, or skipped. This isn't cosmetic state — it's what delivery evidence is built on.
Subscribe to post.draft, post.scheduled, post.published, post.partial, and post.failed — signed, HMAC-verified events instead of polling for a state change. See the full event catalog.
Create a post in whichever state fits your workflow — pending approval, timed for later, or queued into a recurring publishing slot.
Each platform target is rendered, delivered, and retried independently, with its state visible at every step — not just at the end.
A signed webhook or a status read returns the permalink, platform ID, and error detail for every target — the record of what actually published.
The broader picture: connecting accounts, publishing, and the developer surface PostGate exposes end to end.
How one request delivers to many platform targets independently, each with its own status.
Free, Solo, Launch, and Build plans all include drafts, scheduling, queueing, and webhooks — the difference is connected profiles, posting volume, and entitlements like white-label and BYOK.