dev.to's single-article endpoint has no published field, so your publish check reports drafts

Two representations of the same article, and only one of them belongs to the author. The collections under /api/articles/me/* are author-scoped: they describe the post the way its owner sees it, and they echo back the published flag the owner sent on POST or PUT ^[8][7]. GET /api/articles/{id} hands over the article the way an anonymous reader receives it, and that view has no publication state to report, because anything fetchable there is public already ^[9].

The author did not leave that as an assumption. A draft created with published false, id 4449977, returned 404 to an unauthenticated request, and 404 again to the owner's own key ^[10][11]. The endpoint is not filtering fields by permission. It has nothing to say about non-public content at all, so the existence of a response is the state ^[2].

That reframes the problem from a missing field to a misread contract. The loud failure is survivable: article["published"] raises KeyError and the run stops ^[12]. The quiet one costs money. article.get("published") returns None because the key is absent rather than false ^[5], None is falsey, and the branch that handles "not yet published" is usually the branch that retries ^[12]. The publish has already worked. The script pushes again.

The write path offers no cover either. A PUT returned HTTP 200 and a body with no published key, even though published was a field that request had just set ^[6]. You cannot confirm your own write from the response to it.

There is a second difference worth knowing before you compare timestamps across the two views. me/published reported published_at as 2026-08-16T07:13:13.534Z, while the id endpoint reported 2026-08-16T07:13:13Z for the same article ^[2][3]. One carries milliseconds and the other truncates to whole seconds, so string equality between them fails and any ordering inside the same second is lost ^[1]. Cache the author-scoped value, assert against the public one, and the check breaks for reasons unrelated to publication.

Scope, which matters to anyone running their own Forem: one account on dev.to itself, API v1, three published posts and one draft, measured on 2026-08-21 ^[1]. The article under test had been live for five days by then, so a propagation lag is a thin explanation ^[3]. Self-hosted instances, organization articles and scheduled posts were not tested, and a self-hosted Forem can run several versions behind ^[15]. That is the case for probing reachability rather than reading a flag ^[13]: the probe does not care which version of the software is answering.