Every social publishing API can tell you a request was accepted. Almost none of them can tell you, per destination, that a post actually landed — with the platform's own post ID and permalink to prove it. That gap is why schedulers say "published" for posts nobody can find, and why customers find out from a missing post, not from the tool. We call the thing that closes that gap delivery evidence, and it is built into every post PostGate sends.
A unified post sent to five profiles is five independent deliveries. Each target moves through its own lifecycle — pending, media_ready, publishing, and sometimes reconciling or retry_scheduled — before reaching a terminal state: published, failed, or skipped. A tool that only exposes one status for the whole post has already thrown this information away.
A target only reaches published once the destination network hands back a real platform_post_id and permalink. That is evidence the network itself created something addressable — proof from the platform, not a status PostGate assigned to its own internal job.
A post with one published target and one failed target is partial — not rounded up to success, not rounded down to failure. You keep the working permalinks and act only on what actually broke, because the evidence is granular enough to tell them apart.
Fire-and-forward is simple: accept a request, hand it to the platform, return 200. Tracking every target through its own state machine — including retries, reconciliation after a timeout, and a distinct terminal outcome per destination — is real infrastructure most publishing tools never built, because it only pays off when something goes wrong.
A calendar with one badge per post is simpler to design than one that can show five different outcomes for a single scheduled item. Collapsing target-level truth into a single aggregate flag is a product shortcut, and it is exactly the shortcut that produces a false "published."
Showing a customer that three of five destinations succeeded and two failed is more honest — and more useful — than showing a single green checkmark. It also means the vendor has to build real retry and reconciliation logic instead of quietly hoping every call succeeds on the first try.
Subscribe to post.published, post.partial, and post.failed and PostGate pushes each terminal outcome to your endpoint the moment every target resolves — with the platform post IDs and permalinks attached, signed with HMAC-SHA256 so you can verify the payload came from PostGate before you trust it.
A stable Idempotency-Key on the create call makes the logical request replayable for 72 hours without risk of double-posting. If your client times out waiting for a response, retry with the same key and get back the same post — not a duplicate one — while delivery evidence keeps tracking the original targets underneath.
A target that stalls because a connection needs re-authorization is not silently retried forever and not marked as a generic failure — it lands in awaiting_reconnect, a state your product can surface to the customer directly, with the profile health endpoint explaining exactly why.
Every post created through PostGate carries this from the first call — no separate plan, no add-on. Read it directly from the post, or subscribe to webhooks and let PostGate push it to you.
curl https://api.postgate.studio/api/posts/post_01JXYZ \
-H "Authorization: Bearer $POSTGATE_API_KEY"
{
"id": "post_01JXYZ",
"status": "partial",
"targets": [
{
"profile_id": "pro_instagram123",
"status": "published",
"platform_post_id": "17895...",
"permalink": "https://instagram.com/p/Cxyz.../"
},
{
"profile_id": "pro_linkedin456",
"status": "failed",
"error": { "code": "platform_transient", "retryable": true }
}
]
}