So I built LazyRelay to do one more step. It sends the post. Then it goes back and reads from the platform to see if the post exists and is public.

What the check can tell you: the platform says the post exists and is public. What it cannot tell you: that everyone sees it. I try not to promise more than that.

What is still hard: tokens that expire, media that fails, and platforms that answer slowly. When LazyRelay cannot confirm a post, it flags it in the dashboard so you find out before your audience does.

How do you check that a scheduled post is really visible?

If you want to see how it works: https://lazyrelay.com/verify-post-published/

Here are four ways that happens.

1. A 200 is not the post

My first version of the read-back check fetched the public page and treated HTTP 200 as "live". That passes for a maintenance page, a parked domain, a "coming soon" plugin, or a password-protected post whose public page is just a password form. All of them answer 200.

The fix: read a small part of the page and require the post's title or its slug to appear in it. If the proof cannot name the post, it is not proof.

2. The URL in the response is not yours to trust

The read-back used the link the platform sent back. On a blog with a custom domain, that domain is controlled by the customer. It can answer with a redirect to an address inside your own network, and a naive fetch follows it and reports success.

The fix: do not follow redirects blindly. Check every hop, require the final host to match the expected host, and never send credentials past the first host.

3. A timeout does not mean "it did not happen"

If the create request times out, the platform may still have created the post. A scheduler that retries now publishes it twice, in public.

The fix: after a network error, look for a post with the same title from the last few minutes before you report a failure, and if you cannot tell, say so instead of retrying blindly.

4. "Saved as a draft" is not a failure

Some customers choose to save a draft on the platform instead of publishing. A read-back that insists the post is public will call that a failure and retry it until it gives up. A draft that exists exactly where the customer asked for it is a finished job. It just should not be counted as published.

The fix: give "saved as a draft" its own ending, so it is never retried and never inflates a "verified live" number.

The pattern

In all four, the code checked the easy thing (did the server answer?) instead of the thing I actually care about (can a stranger see this post?). Whenever a system reports success, ask what it actually observed, and whether that observation could be true while the post is not live.

I use this idea in LazyRelay, the scheduler I am building: after every post it reads the platform back to confirm the post is really there. You can look at it at https://lazyrelay.com.

What is the strangest "success" you have seen an API report?

The gap

Every platform's "create post" endpoint can return 200 OK and a post ID, and the content still isn't live. A few real ways that happens:

• The platform accepts the write, then silently rejects it a few seconds later during async moderation.
• Media processing fails after the initial call succeeds, before the post actually renders.
• The account hits a rate limit or shadow restriction that doesn't surface as an error on the write itself.
• A token has a narrower scope than you think, so the write "succeeds" against a sandbox or test context you didn't intend.

If your scheduler treats "the POST call didn't throw" as "it worked," you'll eventually tell a customer their content is live when it isn't — and you won't find out until they do.

What we do instead

After every publish attempt, we make a second, independent read-back call — not trusting the write response, actually re-fetching the post from the platform's API and checking it resolves.

Here's the real shape of it, from our Mastodon adapter:

async verifyPublished(platformPostId: string, accessToken: string): Promise<VerifyResult> {
  const res = await fetch(`${DEFAULT_INSTANCE}/api/v1/statuses/${platformPostId}`, {
    headers: { Authorization: `Bearer ${accessToken}` },
  });
  const json = await res.json();

  if (!res.ok || json.id !== platformPostId) {
    return {
      verifiedLive: false,
      platformPostUrl: null,
      errorMessage: json.error ?? `Mastodon status verification failed (HTTP ${res.status})`,
    };
  }

  return {
    verifiedLive: true,
    platformPostUrl: json.url ?? `${DEFAULT_INSTANCE}/web/statuses/${platformPostId}`,
    errorMessage: null,
  };
}

Every platform adapter implements the same verifyPublished() contract. The scheduler calls it right after the post attempt, before it ever marks anything as done:

const attempt = await adapter.post({ ...content });
if (!attempt.success || !attempt.platformPostId) {
  // handle failure — never reached "verified" state
}

// The post API call succeeding is NOT the same as the content being
// live — this read-back check is the actual differentiator, not an
// optional extra step.
const verification = await adapter.verifyPublished(attempt.platformPostId, accessToken);

if (!verification.verifiedLive) {
  // treated as a real failure, not a success with an asterisk
}

Only after that second call comes back clean does a post get marked verified_live: true and a customer-visible confirmation goes out. If it doesn't, it's a real failure — not a success with an asterisk quietly left off.

Why this is worth the extra call

It's one more HTTP round-trip per post, on top of the write itself. That's a real cost, and I get why most schedulers skip it — it only pays off when something's already gone wrong, which is exactly when it's easy to convince yourself "the API said it worked, so it's fine."

If you're building anything that writes to a third-party API and reports success back to a user, it's worth asking: does "success" mean the call didn't error, or does it mean you went and checked? Those are different guarantees, and only one of them is actually true when you say it.

If you're curious about the rest of it — LazyRelay also ships an MCP server so an AI agent can schedule posts, pull this same verified-live data, and read mentions directly, without a human in the loop for the read side.

This post was originally published on Dev.to.