How to Schedule Hashnode Posts in 2026: The API Just Went Paid, Here's What Works

Short answer: yes, you can still schedule Hashnode posts in 2026, both from the editor and from code. Longer answer: as of May 13, 2026, the code path now requires a paid Pro plan, and it never supported scheduling in the first place. Here's what actually works, and what changed.

What changed in May 2026

On May 13, 2026, Hashnode's changelog quietly confirmed something a lot of API integrations found out the hard way: all API access now requires a Pro plan. The free tier that let hobbyists pull and publish posts through the GraphQL API is gone. If your personal access token sits on a free account, your queries and mutations start failing, not because your code broke, but because the account behind it no longer qualifies.

This matters for anyone who built a publishing pipeline on the assumption that Hashnode's API would stay free indefinitely. It also reframes the whole "should I automate this" question, because now there's a subscription cost attached before you write a single mutation. If you were running a small script that pulled your own posts for a personal site, or auto-publishing from a static-site generator, that script is the first thing to check after this date. A token that worked in April can fail in July for no reason other than the plan behind it.

What you need

• A Hashnode Pro plan. Since May 13, 2026, this is not optional for API access.
• A Personal Access Token (PAT), generated from your account settings.
• Your publicationId, the GraphQL identifier for the blog you're publishing to, not your username or blog URL.
• A GraphQL client of some kind, since Hashnode's API is GraphQL-only. There is no REST equivalent.

Keep the publicationId handy. Every publish call needs it, and it's easy to grab the wrong one if you run more than one publication. You can find it through a me query on your account, or by inspecting the publication settings page, and it's worth saving it as an environment variable next to your PAT so a copy-paste mistake doesn't send an article to the wrong blog.

Native scheduling in the editor (up to 6 months ahead)

The easiest way to schedule a Hashnode post is still the one baked into the editor: write the draft, open the publish options, and set a future date and time. Hashnode's scheduler holds the post and publishes it automatically, and it lets you set dates as far out as 6 months.

This costs nothing extra and needs no PAT, no Pro plan, no GraphQL. If your whole workflow is write it in Hashnode's editor, schedule it, done, you don't need anything below this section. The gap shows up the moment you want to publish from outside the editor, cross-post from another system, or manage a queue of drafts written elsewhere.

Publishing via GraphQL publishPost

If you're generating content externally, whether from a CMS, a script, or a drafting pipeline, you publish it through the publishPost mutation against Hashnode's single GraphQL endpoint at gql.hashnode.com.

mutation PublishPost($input: PublishPostInput!) {
  publishPost(input: $input) {
    post {
      id
      slug
    }
  }
}

Authentication is a header, not a bearer token in the usual sense:

Authorization: <your-personal-access-token>

That's the trap. Your instinct from every other API you've touched is to send Authorization: Bearer <token>. Don't. Hashnode wants the raw PAT with no prefix, and adding "Bearer" in front of it doesn't throw a helpful error, it just silently fails. If your calls are returning auth errors and the token looks right, check for a stray "Bearer" first.

You'll also need your publicationId in the mutation input alongside title, content as Markdown, tags, and any cover image. There's no draft-then-publish two-step here the way some platforms handle it. publishPost publishes.

See how TimeToPost can help you implement these strategies.

Why external schedulers exist (no schedule mutation in the API)

Here's the part that trips people up: the GraphQL API has no scheduling field. There is no scheduled-publish argument, no separate draft mutation that later flips to published, nothing. publishPost publishes immediately, full stop.

That's genuinely strange, because native editor scheduling exists and clearly works server-side somewhere. It's just not exposed as a mutation you can call. So if you want to queue up a week of Hashnode posts and have them go out at set times from your own pipeline, the API alone can't do it. You either use the editor's built-in scheduler for each post by hand, or you build, or use, an external system that holds your content and fires the publishPost call at the right moment. That's exactly the gap third-party schedulers exist to fill.

Rate limits are worth knowing before you build a queue of your own. Hashnode is commonly reported to run around 20,000 queries and 500 mutations per minute, though that figure comes from secondary sources rather than a published hard limit, so treat it as a ballpark, not a contract.

Scheduling your Hashnode promo posts to X and LinkedIn with TimeToPost

Publishing the article is one job. Telling people it exists is a separate one, and it's the job that actually gets neglected. A Hashnode post that goes out at 9am with no promotion behind it gets read by whoever happens to check your blog that day, which for most of us is close to nobody.

TimeToPost doesn't connect to Hashnode directly today, so it won't fire your publishPost call for you. What it's built for is the layer around the article: once your post is written or scheduled in Hashnode, drop the promo copy into TimeToPost's calendar and schedule the X and LinkedIn posts that point back at it, timed against when your audience actually reads rather than whenever you remember to hit share. Pair every article with a same-day and a next-day promo post, use the posting schedule generator to lay out a week of both at once, and run the whole thing from one calendar instead of jumping between Hashnode's editor and two other apps.

Limits and rules worth knowing

• The API is GraphQL-only, at gql.hashnode.com. There's no REST fallback.
• PATs go in the Authorization header raw, with no "Bearer" prefix.
• All API access requires Hashnode Pro as of the May 13, 2026 changelog.
• Native editor scheduling exists and works up to 6 months out, but has no API equivalent.
• Rate limits are commonly cited around 20k queries and 500 mutations per minute, unofficial, and worth padding for.

FAQ

Is the Hashnode API free? Not anymore. As of the May 13, 2026 changelog, all API access, including read queries, requires a Pro plan. A free-tier PAT stops working.

Do I need to add "Bearer" before my token? No. Send your PAT as-is in the Authorization header. Adding "Bearer" in front of it causes requests to fail silently instead of returning a clear error, so this is the first thing to check when auth breaks.

Can the API schedule posts for me? No. publishPost publishes immediately and there is no scheduling parameter or mutation anywhere in the GraphQL schema. Scheduling only exists in the native editor UI. To schedule programmatically, you need an external system that holds your content and calls publishPost at the right time.

If you're posting to Hashnode and to social from the same content calendar, that's the workflow TimeToPost is built for, even without a direct Hashnode connector yet.