How to Schedule Dev.to Posts With the Forem API (No Native Scheduler, One Honest Workaround)

Short answer: Dev.to's API cannot schedule a post for you. There is no publish_at field, no scheduled_for parameter, nothing in the schema that holds a timestamp and fires later. If you have been searching for one, stop, you are not missing a hidden option.

Longer answer: you can still get the exact same result, draft now, publish at 9am next Tuesday, you just have to build the clock yourself. This is the honest version of how that works, including the one workaround that actually holds up.

What you need (API key from Settings > Extensions)

Dev.to runs on the open-source Forem platform, and its REST API lives at dev.to/api. To use it you need a Dev.to account and an API key.

• Log into Dev.to.
• Go to Settings > Extensions.
• Generate an API key. It is a personal key tied to your account, not an OAuth app, so there is no client ID or redirect flow to wire up.
• Send it on every request as an api-key header. Not Authorization: Bearer, not a query param, just api-key: your-key-here.

The API is versioned, and v1 is current. Set the accept header to application/vnd.forem.api-v1+json so you get the version you are actually testing against, rather than whatever the default happens to be that week.

Publishing via POST /articles

Creating an article, whether you want it live immediately or sitting as a draft, is one call:

POST https://dev.to/api/articles

The fields that matter for a scheduling workflow:

• title (string, required)
• body_markdown (string, your actual post content)
• published (boolean, defaults to false)
• tags (array of strings, up to four)
• series (string, groups posts into a series on your profile)
• canonical_url (string, more on this below)
• main_image (string, cover image URL)

A minimal request body wraps all of that in an article object:

{
  "article": {
    "title": "Your title here",
    "body_markdown": "Your post content in markdown",
    "published": false,
    "tags": ["webdev", "api"]
  }
}

Leave published as false and the article sits as a private draft on your account, visible only to you, not indexed, not in anyone's feed. That default is doing all the work for the workaround below.

The scheduling gap: no publish_at exists

Here is the part worth saying plainly. The /articles schema has no time-based field of any kind. You cannot pass a future date and expect Dev.to to hold the post and release it. Whatever gets returned from POST /articles is either published right now (if published: true) or sitting as a draft forever, until something explicitly flips it.

This is not a bug or an oversight buried in changelog notes, it is just the shape of the API as documented. If you want a post to go live at a specific time, you are the scheduler. Dev.to gives you the storage and the publish switch, not the clock.

The workaround: draft now, flip published on schedule

The pattern that actually works is two calls, separated by time:

1. POST /articles with published: false to create the draft whenever you write it, days or weeks before it needs to go out.
2. PUT /articles/{id} at the moment you want it live, setting published: true.

That second call is the entire "scheduler." It is just a timer, cron job, or queued task that fires a PUT request at the right minute. Store the article id you get back from step one, keep it next to your target publish time in whatever job store you use, and let the timer do the rest.

It is a workaround, not a feature, and it is worth treating it that way. If your timer job dies, your post never flips, and there is no Dev.to-side fallback watching for that. Build in a way to notice a missed flip, even something as simple as a daily check for drafts past their intended publish time.

Cross-posting right: canonical_url

If the post you are scheduling to Dev.to already lives somewhere else first, your own blog, a company site, Substack, whatever, set canonical_url to point at the original. This tells search engines the original is the source of truth and Dev.to is a syndicated copy, which avoids duplicate-content problems and keeps your SEO credit where you actually want it.

This matters more than it sounds like it should for a scheduling workflow, because the natural pattern for most people is: publish the long article on your own site first, then queue the Dev.to version to go out a day or two later as a companion post. canonical_url is the field that makes that safe to do repeatedly without Dev.to and your own site fighting each other in search results.

Pairing each article with scheduled social promo in TimeToPost

Dev.to does not have a connector in TimeToPost today, and we are not going to pretend it does. What we do well is the layer around it: the calendar that holds "this article goes live Tuesday at 9am" next to "and here is the X post, the LinkedIn post, and the Threads post that go out the same morning to point at it."

In practice that looks like: your PUT-to-publish job fires the Dev.to flip, and in the same window, drafts you already wrote in TimeToPost's calendar for the platforms it does connect to go out alongside it. The character counter keeps your promo copy inside each platform's limit, the calendar keeps the whole launch synced to one timestamp instead of you remembering to post about it later, and the posting schedule generator gives you a cadence to fill in around it if you are running a regular Dev.to series rather than a one-off post.

If you are trying to figure out when that Tuesday-morning slot should actually be, our best time to post breakdown for 2026 is a reasonable starting point, though for a technical audience reading Dev.to specifically, your own analytics over a few weeks will beat any general study.

FAQ

What are Dev.to's API rate limits? There is no documented numeric rate limit published in the official API docs as of this writing. Treat any specific number you see quoted elsewhere as undocumented and unverified, and build in basic backoff and retry handling rather than assuming a fixed ceiling.

Do I have to send front matter or JSON? Both work. The API itself takes JSON in the request body, the fields shown above. Separately, Dev.to's markdown editor supports YAML front matter (title, published, tags, and so on) if you are writing and pasting manually rather than going through the API. For an automated scheduling workflow, JSON via the API is the more reliable path since you are not parsing your own markdown to extract metadata.

Can I add a post to a series through the API? Yes. Pass a series string in the article object and Dev.to groups it with any other articles under that same series name on your profile, in the order you publish them.

Can I edit a post after it is published? Yes, the same PUT /articles/{id} call you use to flip published to true works for any other field afterward, title, body, tags, canonical_url. There is no separate "locked after publish" state in the API.

Dev.to rewards showing up consistently more than it rewards any particular hour of the day. The API gives you the publish switch, you supply the clock, and everything else, the promo posts, the cadence, the reminder that a draft has been sitting unflipped for three days, is calendar work. That is the part worth automating properly.