Every time I copied a post into the dev.to editor, added tags and cleaned up the formatting, I'd wonder whether there was a way to automate it. If ...
For further actions, you may consider blocking this person and/or reporting abuse
Very Nice guide Julie! It's short and very understandable :D
I tend to post on the dev.to "create post". If you are using the dev.to API, it's important to note to make sure no one has access to the API keys you have. The reason why I don't use dev.to api to post is mainly of fear of leaking my own API key lol. I only use it to display my posts in a friendly format through my portfolio. Creativity is always fun :)
If anything, I think a good project is making your own dev.to editor with the dev.to api. I can imagine it looks not only nice, but very convenient as well. I think Sloan uses the dev.to API to automatically send Welcome Threads, but @ben can correct me if I am wrong.
Well done!
Thank you, Francis!😄 I’m glad it’s easy to follow.
So you don't use the dev.to API to post because you're worried about leaking your API key? You seem very security-conscious — I like that.😄
Are the articles on your website linked to dev.to via the API? It's wonderful. When I first saw your website, I was impressed by that, and I wondered how you did it.
As for building my own dev.to editor using the API, I'm afraid it wouldn't be as convenient or full-featured as dev.to’s built-in editor.
Nice and practical guide, Julie! 😊
I particularly like the Markdown front matter approach. It makes publishing much easier to automate.
One small suggestion: since published is set to False, the success message could say “Draft created” instead of “Published.”
It might also be worth mentioning duplicate prevention. Running the script twice creates two separate articles unless the existing article ID is tracked and updates use the appropriate API endpoint.
Thanks for sharing such a beginner-friendly walkthrough!
Thank you, Mustafa!😄I’m glad you like it. I also prefer the Markdown front matter approach, since typing or pasting the entire body on the command line is too much work.
Thanks for the suggestion. You’re right: since it is a draft, it would be better to set the success message to either “Draft created” or “Succeeded”. I've made the change in the post.
By “duplication prevention,” do you mean we should avoid running the script more than once on the same article when updating it? Yes, that's right. While testing the script, I ran it twice, and two drafts of the same article appeared in the dashboard.
Exactly, Julie! 😄 That’s precisely what I meant.
When we run the script again for the same Markdown file, it creates another draft instead of updating the existing one. As you noticed during testing, it’s surprisingly easy to end up with duplicates. 😅
One simple approach would be to save the article ID returned by the API after the first successful creation. On subsequent runs, the script could use that ID to update the existing article rather than creating a new one.
Of course, that’s probably a topic for a follow-up article. Your current guide does a great job of keeping things simple and approachable for beginners.
And thank you for taking the time to update the success message! I really appreciate how open you are to feedback. That’s one of my favorite things about this community. 😊❤️
Looking forward to your next post!
Mustafa, thank you for pointing this out! 😊You took these cases into account and made the post more complete.
I found that the API has a PUT method for updating a published article by its ID Forem API V1 | Forem Docs, but I didn’t know where to get that ID.
Really clear walkthrough! Using the API for cross-posting developer notes and engineering logs directly from automated pipelines saves so much manual context switching. The tip on structuring frontmatter tags cleanly is super helpful.
Thank you! 😄I’m glad it’s helpful. Automation makes publishing posts easier.
A more subtle failure shows up when publishing versioned technical documentation at scale. Imagine generating DEV articles from a repository covering a distributed system: an article for v2.4 references an API contract that changed in v2.5, while its code samples still compile against the newer SDK. The Markdown is valid, the API accepts the post, but the technical explanation is now internally inconsistent. I'd validate code samples and version-specific references against the target release before creating the article, then publish only after those checks pass. Otherwise, automation can scale outdated technical guidance just as efficiently as accurate content.
Yes, we need to keep a human in the loop. I set
publishedtofalse, so the post is saved as a draft on dev.to, and you can check it again before publishing.That helps with the publishing side, but I’d still separate human review from technical validation. For example, if an article documents a Kubernetes upgrade and includes Helm values, deprecated API fields, and commands tied to a specific cluster version, a reviewer can approve the draft without catching a mismatch that only shows up against the target version. Running the examples in a version-pinned environment before the draft is even created would catch a different class of errors. The draft gives you a checkpoint; reproducible validation gives you stronger evidence to review.
The draft-first step is a good boundary for this workflow. One failure case worth covering is a request that times out after the server has already created the draft: immediately retrying POST can duplicate it. I would check the dashboard before retrying an ambiguous result, and add a request timeout so a stalled call does not hang the script.
I'd add a quick check for link fragments when cross-posting. An image can load and the canonical URL can be correct, while a table-of-contents link still points to a heading ID from the original site. I'd open a couple of those jumps in the DEV draft before publishing, especially on longer posts. That is easy to miss when the Markdown itself looks fine.