A successful API request is not a published post: lessons from CozyCue

Description and use

Verification through CozyCue revealed that a successful API request does not guarantee post visibility. A checklist was introduced to verify account, content type, visibility, and actual publication to avoid duplicates and errors.

Problem

A successful API request does not guarantee that a post is actually published and visible to the public.

Outcome

Implementing a step-by-step verification checklist prevents false positives in publishing pipelines and ensures that content is truly visible to the intended audience.

Workflow

• Check the destination first: confirm account, content type, and visibility before sending a test.
• Submit one identifiable post with a unique title and keep the local job reference.
• Record the platform result: ensure the worker retains the remote post ID or URL.
• Open the destination: verify the article or post, its text, image, and intended visibility, including a check without the publishing account’s session.
• Separate infrastructure health from publishing success: confirm that the container is running and HTTP 200 responses do not guarantee public visibility; wait for relay acknowledgement in asynchronous APIs.
• Iterate and correct errors such as signing-key format mismatches before reporting success.

Evidence

A channel connection only proves that credentials were accepted. It does not prove that the account can publish publicly, that its media is supported, or that a queued job will finish.

Source

Check the destination first. Confirm the account, content type, and visibility before sending a test.

Source

Submit one identifiable post. Use a unique title and retain the local job reference.

Source

Separate infrastructure health from publishing success. A running container and an HTTP 200 response do not tell us whether a reader can see the content.

Source