Post Lifecycle

A post is draft, scheduled or publishing, then published, partial or failed, and cancelled once every platform copy has been removed. Read post.status with GET /v1/posts/{postId}, or let a post webhook tell you when it changes. The status names what you can still do with the post and which event to expect next.

draft ──► scheduled ──► publishing ──► published
                            │      └──► partial
                            └─────────► failed
published / partial ──► cancelled   (via unpublish)

First call

Call GET /v1/posts/{postId}. The post-level status is an aggregate; each entry in platforms[] carries its own.

import Zernio from '@zernio/node';

const zernio = new Zernio();

const { data: fetched } = await zernio.posts.getPost({
  path: { postId: '65f1c0a9e2b5af0012ab34cd' }
});

console.log(fetched.post.status);

Response (200):

{
  "post": {
    "_id": "65f1c0a9e2b5af0012ab34cd",
    "status": "partial",
    "scheduledFor": "2027-01-01T17:00:00Z",
    "platforms": [
      {
        "platform": "linkedin",
        "status": "published",
        "platformPostUrl": "https://www.linkedin.com/feed/update/urn:li:share:7123456789012345678"
      },
      {
        "platform": "instagram",
        "status": "failed",
        "errorMessage": "Media processing failed: video too short for Reels",
        "errorCategory": "user_content",
        "errorSource": "user"
      }
    ]
  }
}

Post statuses

Which status a new post gets

Create post sets the initial status from the scheduling fields:

publishNow returns 201 when every platform published and 207 when at least one failed. 207 is a 2xx: fetch(...).ok is true and axios resolves, so branch on the status code or on post.status, never on "did it throw".

Per-platform status and errors

Each entry in platforms[] has a status of pending, processing, uploading, published, failed or cancelled, plus platformPostUrl once published. A published entry that later disappears from the platform keeps status: "published" and gets removedFromPlatformAt; detection runs with the analytics sync, so expect up to a few hours of lag.

A failed entry carries a human-readable errorMessage and two machine-readable fields:

errorSource (user, platform, system) says who can fix it: user errors need action from you or your user; platform and system errors are worth retrying.

What you can do in each state

Tracking transitions with webhooks

Each transition fires a post webhook:

The per-platform events are the fastest signal: a post targeting 5 platforms emits them one by one as each platform finishes, while the aggregate event waits for all 5. For publishNow: true you need no webhook: the create response is synchronous and already holds the per-platform results and URLs.

If it fails

A 400 on DELETE /v1/posts/{postId} means the post is published:

{
  "error": "Published posts cannot be deleted",
  "type": "invalid_request_error",
  "code": "invalid_resource_state"
}

Take the post down from each platform with unpublish first, or leave it and delete nothing: the record stays as the source of platformPostUrl and analytics.

Related

• Error handling: the error envelope and the retry endpoint.
• Idempotency & safe retries: avoid double-posting when you retry creates.
• Queue scheduling: let Zernio assign the publish time.
• Post webhooks: the payload of each event above.