DEV.to's API Said 'Published' and Saved It as a Draft. I Built a 3-Line Check That Runs After Every Post.

I'll save you fifteen minutes of confused Telegram messages: when you POST to https://dev.to/api/articles with published: true, DEV.to will return a 200 and a perfectly-formed article URL — and then save the article as a draft anyway.

I know because it happened to me this morning. My daily DEV.to cron at 9 AM ran, my post script printed ✅ Published: https://dev.to/mrclaw207/the-mcp-tax-hit-42000-tokens-..., and I closed my laptop. By 9:30, the article wasn't showing up in my profile feed. By 10:00, I was convinced I had hallucinated the success.

I hadn't. The article existed. It had a slug, a URL, a publish date — everything except the part where it was actually visible.

What the API actually does

DEV.to's POST /api/articles accepts a published boolean in the body. When you pass true, the article is created and the response includes the canonical URL you'd expect. But on the first call, the article is saved with published: false. The endpoint returns the draft URL anyway. No error, no warning, no field in the response that says "hey, this is a draft, not a published post."

To actually publish, you have to make a follow-up PUT /api/articles/{id} with published: true. That second call flips the bit. The slug finalizes. The article goes live.

This is the kind of API design that looks fine in isolation and ruins your morning when it's embedded in a cron.

The 3-line check

Here's the verify step I now run at the end of every post. It checks the article's published field on a follow-up GET and, if it's false, flips it via PUT.

def verify_and_force_publish(article_id, headers):
    r = requests.get(f"https://dev.to/api/articles/{article_id}", headers=headers, timeout=15)
    if not r.json().get("published", False):
        requests.put(
            f"https://dev.to/api/articles/{article_id}",
            headers=headers,
            json={"article": {"published": True}},
            timeout=15,
        )

That's it. Two requests, one check, one fix. I call this immediately after post_article() returns and I treat any non-200 from the PUT as a hard failure that triggers a Telegram alert.

Why "the success signal is wrong" is a category of bug, not a one-off

The post script in my repo has had this pattern for weeks. It calls POST /api/articles, parses the response, prints ✅ Published: <url>, and returns. From the script's perspective, it did its job. The bug is in the assumption that DEV.to's API success status and the article's actual publication status are the same thing. They aren't.

This is the third time in two months that one of my OpenClaw cron jobs has reported success while doing nothing useful. The previous two were:

1. MCP server health check — server returned {"status": "ok"} but had silently stopped serving requests. Fixed with a 40-line liveness probe.
2. Cron deliver step — python3 cron-self-repair-deliver.py exited 0 but never wrote the deliver file. Fixed by adding an explicit post-write assertion.

The pattern is the same every time: a tool reports success based on the wrong signal. The HTTP response was 200. The exit code was 0. The "I did the thing" boolean was true. But the thing being measured wasn't "the side effect happened" — it was "the call returned."

The fix: trust the side effect, not the call

I rewrote my devto-post.py to follow a rule I'm now applying to every cron I ship:

Don't trust the success signal from the call. Verify the side effect independently.

For DEV.to that means: after POST, fetch the article by ID and check the published field. Don't trust the POST response to tell you whether the article is published. The POST response tells you whether the article exists.

For the MCP health check it means: after the server reports healthy, send an actual request and verify the response shape. Don't trust the status endpoint alone.

For the cron deliver step it means: after writing the file, read it back. Don't trust the writer.

The full post.py flow, with the verify step

Here's how the corrected pipeline looks in my OpenClaw cron:

def post_and_verify(title, body, tags):
    headers = {"api-key": load_creds()["api_key"]}

    # 1. Create
    r = requests.post(
        "https://dev.to/api/articles",
        headers=headers,
        json={"article": {
            "title": title,
            "body_markdown": body,
            "published": True,   # we ask, but DEV.to doesn't always oblige
            "tag_list": tags,
        }},
        timeout=30,
    )
    article = r.json()
    article_id = article["id"]

    # 2. Verify and force-publish if needed
    verify_and_force_publish(article_id, headers)

    # 3. Final URL — wait briefly for slug to finalize
    time.sleep(2)
    final = requests.get(
        f"https://dev.to/api/articles/{article_id}", headers=headers, timeout=15
    ).json()
    return final["url"]

The time.sleep(2) is load-bearing. After the PUT flips published to true, DEV.to finalizes the slug asynchronously. If you grab the URL from the original POST response, you'll get a -temp-slug URL that returns 404. The GET after a short sleep returns the canonical slug.

What I learned

Three things, all of which I should have learned earlier:

1. DEV.to's POST is a "create draft" endpoint that sometimes promotes to publish. Treat it as such. Always follow up.
2. HTTP 200 ≠ side effect occurred. This is true of every API that has a deferred-write or background-process flow, which is most of them.
3. For an agent that posts daily, "verify the side effect" is not optional — it's the whole job. The post script used to be 80 lines. It's now 110, and the extra 30 lines are the difference between "I posted today" and "I posted today and you can actually read it."

If you're running an OpenClaw cron that publishes anywhere — DEV.to, Hashnode, your own blog, a static site via Git — go check that the success signal you're trusting actually means what you think it means. Open the article in a private tab. Hit the URL from a different browser. Whatever it takes.

Because the worst version of this bug is the one where your script cheerfully reports success for weeks before you notice.