What counts as proof that a post published?
A post counts as published only when a follow-up check finds the expected object on the intended account and matches its important attributes. A successful publishing response is evidence that the platform accepted or processed a request, not proof that the post became publicly available.
Store the platform's returned post identifier, account identifier, creation time, text, media references, and any returned permalink. Then read the post back using the platform's read endpoint or resolve its public page where permitted. Compare the returned object with the original request, rather than checking only whether an identifier exists.
A useful verification result has three possible states: confirmed, not found yet, or failed. Avoid treating not found yet as failure when a platform processes posts asynchronously. Give the platform a defined observation window, then check again. Also distinguish a private, restricted, or moderation-held post from a missing post. The operator needs to know whether the post exists but is not publicly visible, or whether no matching object was created. That distinction prevents both false success and unnecessary retries.
How do I verify a post against the intended account?
Verify the returned post's account identity before checking its text or permalink. A valid post on the wrong account is still a publishing failure, especially when one operator manages several brands and connected channels.
Save the intended account's stable platform identifier when the connection is created. At verification time, compare that identifier with the author, owner, or container identifier returned for the post. Do not rely on a display name, handle, profile photo, or workspace label because those values can change or be duplicated.
The check should also confirm the connection used for the request. A token can remain valid while pointing to a different account, page, profile, or organisation than the operator selected. Record the account identifier alongside the job, not only in a separate connection table that may later be changed.
For an agency, show both the client label and the platform account identity in the activity record. When the identities disagree, stop verification and flag the job for review. Do not silently move the post into a different account's history simply because the returned object is otherwise valid.
Which fields should a read-back check compare?
Compare fields that identify the intended post and fields that prove the published content is correct. The minimum useful comparison is account identity, post identifier, text, media, destination, and publication state.
Text comparison should use a deliberate normalization rule. Decide whether line-ending differences, trailing spaces, Unicode normalization, links, or platform-added formatting count as meaningful before building the verifier. Preserve the original text as submitted so an operator can inspect the exact difference later. Do not compare only a short prefix, because two posts can share an opening sentence.
Media needs its own comparison. A returned attachment identifier is stronger evidence than a filename, while a public media URL may expire or redirect. Compare the expected number of attachments, their type, and their stable identifiers where the platform exposes them. For links, confirm the intended destination rather than trusting a displayed title generated by the platform.
Keep the original request and read-back response together. A verifier that records only pass or fail cannot explain whether the platform changed formatting, dropped an attachment, used the wrong destination, or returned a different object.
When should an asynchronous post be checked again?
Check an asynchronous post again when the platform has accepted the request but has not yet produced a final, readable object. Verification should follow a bounded schedule, not an immediate single lookup or an endless polling loop.
Use the platform's documented lifecycle when one exists. A publishing operation may move through accepted, processing, published, rejected, or unavailable states. Treat each state according to its meaning. Accepted means the platform has work to do. Published means the platform reports a completed object. Rejected and unavailable require an operator-facing outcome, not another blind attempt.
Choose a maximum verification window appropriate to the content type and platform, then record every check with its timestamp. Space checks out rather than repeatedly asking for the same object. Stop when the post is confirmed, a final failure is reported, or the observation window closes.
Rules, permissions, and lifecycle behavior can change, so the platform's current developer documentation should define the implementation details. A practical user interface can say “awaiting confirmation” while checks continue, then show the last observed state and next action. That wording is more accurate than showing “published” immediately after submission.
How do I confirm a public permalink is the right one?
Confirm a permalink by resolving it to the same post identifier and account, not merely by checking that the link opens. A live page can point to a different object after a redirect, account switch, deleted post, or platform-generated preview.
When a platform returns a canonical URL, store it with the post identifier and use it as an operator-facing reference. If the platform does not return one, construct or resolve a link only according to its documented format. Do not infer a URL from a display name or timestamp when a stable identifier is available.
A public page check is useful but incomplete. Logged-out visibility may differ from visibility for the connected account, followers, or workspace members. Some posts are deliberately private, limited by audience settings, held for review, or hidden by regional and account restrictions. Mark those outcomes separately from “not found.”
The strongest check combines object lookup with permalink inspection where the platform allows both. Compare the resolved account, identifier, text summary, and publication state. If the public page is unavailable but the authenticated object is present, report “published with limited public visibility” rather than claiming that the post failed.
Should I retry when verification cannot find the post?
Do not retry a publish operation merely because the first verification lookup found nothing. A missing read-back can mean delayed processing, an incorrect lookup, restricted visibility, a transient read failure, or a genuinely unsuccessful publish.
First, use the submission's returned identifier and the intended account identity for the next lookup. Searching by text is a poor fallback because duplicate posts, formatting changes, and search delays make the result ambiguous. Next, check whether the platform reports a processing or rejection state. Only after the verification window closes should the job become eligible for another submission.
Every retry needs an idempotency strategy. Reuse a platform-supported idempotency key when available, or maintain a client-side job key and search for an existing matching object before submitting again. Store the attempt history so an operator can see whether a second attempt created a duplicate.
A safe retry rule is simple: retry only when the original attempt is known to have failed or the platform confirms that no object exists. When evidence is incomplete, hold the job for another check or human review. Duplicate content is often harder to undo than a delayed post is to explain.
How do I verify images, video, and link previews?
Verify each attachment independently because a post can exist while one image, video, document, or preview is missing or altered. A text-only read-back cannot certify a media post.
Compare the returned attachment count and types with the request first. Then compare stable attachment identifiers, processing states, dimensions, duration, or other fields the platform exposes. A filename is not proof that the correct file arrived, and a temporary upload URL is not proof that the platform attached it to the post.
Video often needs a separate processing check after the post object exists. Do not label a video fully published while it remains processing, blocked, or unavailable. Link previews also deserve a separate result because the post may contain the link even when the preview image or title was generated differently.
Keep original media metadata available for diagnosis, including a content hash where the workflow can calculate one. A hash does not replace the platform's attachment identifier, but it helps identify whether the submitted local file was the one selected. Show partial success clearly, such as “post confirmed, video still processing,” instead of reducing the entire result to a misleading pass or fail.
What should an operator see after verification fails?
An operator should see the last confirmed fact, the unresolved question, and the next action. “Published” and “failed” are too vague when the system has only partial evidence.
A useful record includes the intended account, submission time, attempt count, returned post identifier if any, last verification time, observed state, and a direct review link when available. Add a concise reason such as “object not found after observation window,” “account identity did not match,” or “text matched but attachment was missing.” Avoid exposing internal implementation details as the primary explanation.
For multiple clients, filter results by account and group duplicate or uncertain attempts together. An operator should be able to distinguish a delayed confirmation from a second post that may have been created by a retry. Keep the original request beside the observed result so a human can make a decision without searching logs.
PostWharf can make this workflow easier to operate by treating verification as a first-class result rather than a hidden technical check. The same principle applies to a custom publisher or to an agent publishing through MCP: do not let the agent report completion until the evidence meets the verification rule selected for that channel.
Sources consulted: Meta for Developers (developers.facebook.com) · X Developer Platform (developer.x.com) · LinkedIn Developers (developer.linkedin.com) · TikTok for Developers (developers.tiktok.com)
Common questions
Does a successful API response prove that a social post was published?
No. A successful response usually proves that the platform accepted or processed the request. The post may still be queued, rejected during processing, attached to the wrong account, or missing media. Confirm publication with a follow-up read that matches the post identifier, account, content, attachments, and final state.
What is the best way to detect duplicate posts after a retry?
Save a client-side job identifier, the original request, and every returned platform post identifier. Before retrying, check for an existing matching object on the intended account. Use platform-supported idempotency where available, and compare content and media carefully because identical text alone can match an unrelated post.
How long should I wait before deciding that a post failed?
Use the platform's documented processing behavior and define a maximum observation window for each content type. Check more than once when processing is asynchronous. If no final state or matching object appears before the window closes, mark the result unconfirmed and require review or a controlled retry.
Can a post be published but not visible publicly?
Yes. Audience settings, moderation, privacy, account restrictions, regional rules, and processing can affect public visibility. Check the authenticated post object and its visibility state separately from a logged-out permalink. Report limited visibility explicitly instead of treating every unavailable public page as proof that publishing failed.
What should a social publishing audit log retain?
Retain the intended account identity, original content and media references, submission time, platform post identifier, canonical link, verification attempts, observed states, and retry history. Keep enough information to compare the request with the published object and explain whether a result was confirmed, delayed, partial, or unresolved.
PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.