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

CozyCue is our self-hosted social publishing workspace, built on Postiz. While connecting channels, we learned that “connected”, “queued”, and “published” are different states.
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.
Our practical verification checklist

1. Check the destination first. Confirm the account, content type, and visibility before sending a test. Platform approval and account permissions are separate from a successful login.
2. Submit one identifiable post. Use a unique title and retain the local job reference. If the result is uncertain, inspect the existing attempt before retrying; a blind retry can create duplicates.
3. Record the platform result. A completed worker should retain the remote post ID or URL. For asynchronous APIs, acceptance is only the beginning; processing may still fail.
4. Open the destination. Check the actual article or post, its text, image, and intended visibility. When public access matters, also check without the publishing account’s session.
5. 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. During our Nostr integration test, we corrected a signing-key format mismatch and made the publishing path wait for relay acknowledgement before reporting success. We then checked the resulting public event and its media. That experience reinforced why each stage needs its own evidence. This article is also our first DEV.to integration test through CozyCue. The cover is a screenshot of our public pilot website. CozyCue is still being validated; channel capabilities and approval requirements vary. What do you use as the final success signal in your publishing pipelines? Disclosure: this article was prepared with AI assistance from our project’s integration work.