Publishing
When a post's moment arrives, each channel publishes independently — one failing never blocks the others — with automatic retries, honest partial-failure results, and a read-only status view.
Publishing is per-channel and independent: each placement gets its own run, so one channel failing never blocks or rolls back the others. Once a post has left the draft desk, it becomes a read-only status view that shows what went where and how it did.
The publish lifecycle
A placement publishes on its own timeline. For a timed post, its run waits until the scheduled instant; for Post now, it fires immediately. Each run then re-reads the post from the database (the source of truth, not the queued event), claims the placement, and calls the provider. If the post was unscheduled, deleted, or rescheduled in the meantime, the run cancels or skips instead of publishing stale content.
As placements settle, the post’s status rolls up: Publishing while any are in flight, then Published if every one landed, or Failed if none are still pending and at least one didn’t. See Scheduling for the full status table.
Independent per-channel publishing
Every channel runs separately, so a failure is scoped to its own placement. If your post goes to LinkedIn and X and X rejects it, LinkedIn still publishes — the post lands as a partial result rather than an all-or-nothing failure. The status view then reads as published to the channels that succeeded, with the rest flagged for attention.
Retries and partial failures
Inklate classifies failures rather than blindly retrying them:
- Transient errors (rate limits, brief network blips) retry automatically with backoff. A rate-limited call is safe to retry because it was rejected before anything was created.
- Terminal errors (a rejected body, a missing permission, a dead auth grant) fail that placement without retrying — a retry can’t unsay a banned term or restore a revoked token. An expired grant also flips the channel so you’re prompted to reconnect.
- Indeterminate outcomes (a timeout or 5xx after sending, where the post may or may not have landed) are reconciled by reading back from the provider. If Inklate can’t confirm, the placement is marked unknown and never blind-retried — an ambiguous send must never become a double-post.
Re-publishing a failed post re-arms only the placements that haven’t already landed: channels that published (or are unknown) are left alone, so a retry never double-posts to a channel that already went out.
The read-only status view
A scheduled, publishing, or published post no longer opens in the editable composer — the live “Schedule / Post now” controls make no sense for something already queued or out. Instead it opens a status view that answers when it goes, where it went, and how it did:
- A header stating Scheduled (with the time and lead time), Publishing…, Published, or Couldn’t publish.
- One row per channel with its own status pill, and for a failure, the error and a Reconnect or Retry action.
- A View link to each published post on the platform, plus synced engagement metrics once a placement is live (see Analytics).
- The exact native preview of what will be — or was — posted to the selected channel.
While a post is still scheduled you can Reschedule (back into the editable composer) or Unschedule (return it to a draft) from here.
Where to go next
Calendar and drafts
All posts is a calendar of everything scheduled and published — with a drafts tray, drag-to-reschedule, and conflict-safe moves when a teammate or agent edits underneath you.
Organizations and members
An organization is Inklate's workspace — one per brand or client. Members hold a role, you switch orgs from the sidebar, and inviting teammates is a paid feature.