Proof of post: what actually counts as evidence a post went live
An HTTP 200 is not proof a post exists. What counts as real proof — a platform-issued post ID and permalink, per destination — and where PostGate attaches it to every post.
By André LugProof of post means evidence from the destination platform itself — a platform_post_id the network assigned and a permalink that resolves to real content — tracked per target, not per post. An HTTP 200 from a create-post call is only proof of acceptance. PostGate attaches this evidence to every published target on every post, for free.
"Proof of post" is a simple question with a surprisingly rare answer in this category: can you show, per destination, that a specific post exists on a specific platform — not that your API accepted a request, not that a job finished, but that the network itself created something with an address you can open in a browser? Most social publishing tools cannot answer that question at the target level. PostGate is built so the answer is always available, for free, on every post.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What actually counts as proof?
An HTTP 200 from a create-post call is proof of acceptance, not proof of publication — see Scheduler says published, but the post never appeared for exactly how those two claims come apart in practice. Real proof has to come from the destination platform itself: a platform_post_id the network assigned, and a permalink that resolves to real content when you open it. Anything short of that is a status PostGate (or any other vendor) assigned to its own internal job, not evidence the network did anything.
Why is proof per target, not per post?
A single post sent to five profiles produces five independent outcomes, and proof only means anything when it is tracked at that granularity. PostGate models this directly: every target carries its own status, its own platform_post_id, and its own permalink once it reaches published. This is the same target-level model covered in full on the delivery evidence page — this post won't repeat that explanation, just point at where the proof actually lives.
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 }
}
]
}What are the two ways to get the proof?
You can read it on demand with GET /api/posts/{id}, or you can let PostGate push it to you the moment it exists by subscribing to the post.published, post.partial, and post.failed webhooks — both documented in Delivery lifecycle and Webhooks. Webhooks are the better default for production: they carry the same platform post IDs and permalinks, signed with HMAC-SHA256, without your client needing to poll and guess when a target is done.
Why is this worth building your product around?
Proof of post is not a premium tier or an add-on — every post created through PostGate carries it from the first call. That matters most for the case it's built to catch: a customer support ticket that says "my post never went out." With target-level proof, the answer is a lookup, not a guess — either the permalink exists and you can hand it over, or the target's error tells you exactly what to fix.
Frequently asked questions
How do I get proof that a social media post was published via API?
Two ways: read it on demand with GET /api/posts/{id}, or subscribe to the post.published, post.partial, and post.failed webhooks so PostGate pushes it the moment it exists. Webhooks are the better default for production — they carry the same platform post IDs and permalinks, signed with HMAC-SHA256, without your client needing to poll and guess when a target is done.
Why does proof of publication need to be per target instead of per post?
A single post sent to five profiles produces five independent outcomes, and proof only means anything when it is tracked at that granularity. In PostGate, every target carries its own status, its own platform_post_id, and its own permalink once it reaches published — so a partial result tells you exactly which destination succeeded and which failed.
Is a 200 response from a posting API proof the post exists?
No. An HTTP 200 from a create-post call is proof of acceptance, not proof of publication. Real proof has to come from the destination platform itself: a platform_post_id the network assigned, and a permalink that resolves to real content when you open it. Anything short of that is a status the vendor assigned to its own internal job.
Does proof of post cost extra with PostGate?
No — it is not a premium tier or an add-on. Every post created through PostGate carries target-level proof from the first call. That matters most for support tickets that say "my post never went out": either the permalink exists and you can hand it over, or the target's error tells you exactly what to fix.
