Handling partial-success posts: what "partial" status actually means
PostGate’s real partial aggregate status — some targets published, some failed — and how to handle it correctly instead of rounding the whole post up to success or down to failure.
By André LugA partial result on a multi-destination post is a legitimate, terminal, successful-in-part outcome: at least one target reached published and at least one failed or was skipped. Handle it per target — surface the successful targets' permalinks immediately, and check each failed target's error.code and retryable flag — instead of rounding the whole post up to published or down to failed.
A post sent to five profiles is five independent publish attempts wearing one calendar entry. Treating the result as a single pass/fail outcome throws away exactly the information you need the moment something goes wrong on only one of those five. PostGate models this honestly with a third aggregate outcome — partial — and integrations that don't handle it end up either hiding real failures or discarding real successes.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
What does partial actually mean?
Per Delivery lifecycle, a PostGate post's aggregate status is one of draft, scheduled (waiting), processing (at least one target active), or a terminal outcome: published, partial, failed, or canceled. partial means at least one target reached published and at least one reached failed or skipped— it is a legitimate, terminal, successful-in-part result, not an error state and not a bug in PostGate's reporting.
{
"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 wrong ways to handle a partial result?
- Rounding up to "published." Your calendar shows a green check for a post that only reached two of five destinations. The customer finds out from a missing post, not from your product — the exact scenario in Scheduler says published, but the post never appeared.
- Rounding down to "failed." Your product tells the customer the whole post failed and prompts a manual resend — which, without an idempotency key check, risks republishing to the targets that already succeeded, producing a real duplicate on a platform that worked the first time.
Both mistakes come from the same root cause: an integration that only stores or surfaces the aggregate status and throws away the targets array that would have told it which destinations actually needed attention.
The correct handling: act per target, not per post
Read the targets array on every terminal post and treat each entry independently. Surface the published targets' permalinks to the customer immediately — that work is done and verified. For failed targets, check the error.code and error.retryable flag before doing anything: a retryable transient error might justify a scoped retry against just that target, while a content or authorization error needs a fix, not a resend. See Errors & retries for the full code list.
How do you catch a partial result without polling?
Subscribe to post.partial alongside post.published and post.failed — see Webhooks. Treating post.partial as an afterthought (or not subscribing to it at all) is a common gap: a consumer built to only expect fully-published or fully-failed events will silently mishandle the most common real-world outcome for any post sent to more than one destination.
Frequently asked questions
What statuses can a PostGate post have overall?
The aggregate status is one of draft, scheduled (waiting), processing (at least one target active), or a terminal outcome: published, partial, failed, or canceled. partial specifically means at least one target reached published and at least one reached failed or skipped — a legitimate terminal result, not an error state and not a reporting bug.
What is wrong with treating a partial post as failed?
Rounding down to failed tells the customer the whole post failed and prompts a manual resend — which, without an idempotency key check, risks republishing to the targets that already succeeded, producing a real duplicate on a platform that worked the first time. The mirror mistake, rounding up to published, hides the failed destination until the customer notices the missing post themselves.
Should I retry a post that came back partial?
Not the whole post. Read the targets array and act per entry: published targets are done and verified — surface their permalinks immediately. For each failed target, check error.code and the error.retryable flag first: a retryable transient error might justify a scoped retry against just that target, while a content or authorization error needs a fix, not a resend.
How do I catch partial results without polling?
Subscribe to the post.partial webhook alongside post.published and post.failed. Not subscribing to it — or treating it as an afterthought — is a common gap: a consumer built to only expect fully-published or fully-failed events will silently mishandle the most common real-world outcome for any post sent to more than one destination.
