Post Lifecycle

Overview

Every post in Postnomic follows a defined lifecycle that tracks its status from initial creation through publication and beyond. Understanding these states helps you manage your content workflow effectively.

This row shows the most common path. Not shown: InReview (an optional detour between Draft and Published, available on every blog) and the transitions described below — archiving, which is allowed from any state, and unarchiving, which returns a post to Draft.

Post States

Draft

The initial state for every new post. Drafts are only visible to blog members with Author, Editor, Reviewer, or Admin roles. Use this state while you are actively writing and refining your content.

• Who can create: Authors, Editors, Reviewers, Admins
• Visible to public: No
• Transitions to: InReview (submit for review), Scheduled (schedule), Published (publish), Archived (archive)

InReview

Posts submitted for editorial review before publication. Review is available on every blog and is never forced: authors can submit a completed draft for review instead of leaving it as a draft. Authors cannot publish in any case; publishing requires the Editor role.

Submitting for review requires the post's Review required flag to be set and at least one reviewer to be assigned, and it resets every assigned review to Pending. A review decision does not move the post by itself: a rejected review leaves the post in InReview and blocks publishing until every assigned review is approved.

• Who can submit: Authors, Editors, Reviewers, Admins
• Visible to public: No
• Transitions to: Published (publish, once every assigned review is approved), Archived (archive)

See the Review Workflows guide for details on the review process.

Scheduled

Posts with a future publish date. The post automatically transitions to Published when the scheduled date and time arrives. Content scheduling is available on Pro and Enterprise plans.

A post can only be scheduled while it is in Draft or Scheduled state; scheduling an already scheduled post simply moves the dates. There is no "unschedule" action — to stop a scheduled post from going live, archive it: archiving clears both scheduled dates, and unarchiving later returns the post to Draft.

• Who can schedule: Editors, Reviewers, Admins
• Visible to public: No (until the scheduled date)
• Transitions to: Published (automatically at the scheduled time, or manually), Scheduled (re-scheduled), Archived (archive)

Published

The post is live and visible to all readers through the public API and Client SDKs. Published posts appear in blog listings, are accessible via their slug URL, and can be discovered through search and filtering.

Publishing always stamps the post's publication date with the current time — read Publishing sets the publication date below before you republish an older post.

• Visible to public: Yes
• Transitions to: Unpublished (unpublish, or automatically at the scheduled unpublish date), Archived (archive)

Unpublished

A previously published post that has been taken offline. The content is preserved but is no longer visible to public readers. Use this state to temporarily remove a post that needs corrections or updates.

• Visible to public: No
• Transitions to: Archived (archive)

An unpublished post cannot be published again directly: the publish action accepts only Draft, Scheduled, and InReview posts, and answers 409 Conflict for an unpublished one. The route back online is archive → unarchive (which returns the post to Draft) → publish — and that final publish re-stamps the publication date.

Posts are also unpublished automatically if an unpublish date was set during scheduling.

Archived

The resting state for posts that are no longer relevant but should be retained. Archived posts are not visible to public readers — the public API omits them entirely, so their URLs return 404 Not Found — and they are separated from active content in the dashboard.

Archiving is allowed from any state and clears any scheduled publish and unpublish dates. Unarchiving returns the post to Draft, never straight to Published: republication is always an explicit decision.

• Visible to public: No
• Transitions to: Draft (unarchive)

The post editor's lifecycle actions include an Archive button, but there is no unarchive button in the dashboard. Unarchive through the API, or through the MCP unarchive_post tool:

curl -X POST \
  -H "Authorization: Bearer your_token" \
  https://api.postnomic.com/blogs/{blogId}/posts/{postId}/unarchive

If posts disappeared from your site and nobody archived them deliberately, start with Posts Missing From Your Site.

State Transition Diagram

                    submit for review
    Draft ─────────────────────────────► InReview
      │ │                                    │
      │ │ schedule                           │ publish
      │ ▼                                    │ (all reviews approved)
      │ Scheduled ──────────────────────┐    │
      │           publish (auto/manual) │    │
      │ publish                         ▼    ▼
      └──────────────────────────────► Published
                                           │
                                           │ unpublish (manual or scheduled)
                                           ▼
                                      Unpublished
                                           │
   any state ── archive ──► Archived ◄─────┘
                               │
                               │ unarchive
                               ▼
                             Draft

Publishing sets the publication date

Every publish writes the current time into the post's publishedAt field. That applies to the Publish button, to the publish API endpoint, and to automatic publishing when a scheduled date arrives (which stamps the moment the schedule fired).

This matters most when you recover an older post. Unarchiving a post from 2023 and publishing it again gives it today's publication date — the original date is overwritten, not remembered. Everything that keys off that date follows: the order of your blog listing, the "published on" line on the post, feed and sitemap entries, and any URL you build from the date.

Correcting the publication date

The post update endpoint accepts an optional publishedAt, so a date lost this way can be put back:

curl -X PUT \
  -H "Authorization: Bearer your_token" \
  -H "Content-Type: application/json" \
  -d '{"title":"Your title","slug":"your-slug","content":"<p>…</p>","publishedAt":"2023-04-17T09:30:00Z"}' \
  https://api.postnomic.com/blogs/{blogId}/posts/{postId}

The rules the API enforces:

• Only on a post that has gone live. The post must currently be Published or Unpublished. On any other status — Draft, InReview, Scheduled or Archived — the request is rejected with 400 Bad Request and the message Cannot set PublishedAt on a post with status '<status>'. Post must be Published or Unpublished. The field is never silently ignored.
• Never in the future. A future value is rejected with 400 Bad Request and the message PublishedAt cannot be in the future. Use the schedule endpoint to publish a post at a future date.
• UTC. The value is interpreted as UTC: a value carrying an offset is converted, a value without one is taken as UTC as it stands.
• Omitting it changes nothing. Leave publishedAt out and the stored publication date stays exactly as it was, so existing integrations are unaffected.
• Same permission as any other edit. The Author role on the blog is enough; you do not need Editor.

Two practical points:

• The order matters. Publish first, correct the date second. Setting publishedAt on the draft you just unarchived is rejected with 400, and publishing after correcting would overwrite your correction with the current time.
• The update replaces the post. PUT writes every field in the request body, so fields you leave out are cleared. Read the post first with GET blogs/{blogId}/posts/{postId} and send its current values back together with publishedAt.

The dashboard post editor has no publication-date field: use the API, or the MCP update_post tool, which exposes the same publishedAt parameter under the same rules.

Dates and Timestamps

Each post tracks several dates automatically:

• CreatedAt — When the post was first created
• UpdatedAt — When the post was last modified
• PublishedAt — The time of the most recent publication, rewritten on every publish (correctable through publishedAt on the update endpoint, see above)
• UnpublishedAt — When the post was last taken offline; cleared again by the next publish
• ScheduledPublishDate — The future date when a scheduled post should go live
• ScheduledUnpublishDate — The future date when a published post should be taken offline

Permissions by Role

Roles are ranked Reader → Author → Editor → Reviewer → Admin. Every action is open to the role it requires and to all roles above it.

Approving or rejecting a review additionally requires being the reviewer the review was assigned to.