Publish content

Prepare text and media, fan out to explicit account targets, and preserve independent destination outcomes through retries and reconciliation.

A publication request records application intent. It has shared content, explicit account targets, optional target overrides, and an idempotency key. Each target receives an independent delivery outcome.

Prepare locally

Preparation validates known content combinations, references, target ownership, capability declarations, and media inputs without uploading or publishing. It should report missing fields and warnings before a network call. Preparation never crops, truncates, rewrites, changes visibility, or adds a destination to make a request pass.

Interpret results

published requires a destination-specific native post reference. accepted and processing remain pending. A failed target can coexist with a published target. An uncertain write must be reconciled before a retry that could create public content twice.

The per-target lifecycle diagram shows why a single aggregate status cannot stand in for destination results. Media uploads, video processing, scheduling, cancellation, and removal each have additional backend and platform constraints; consult the adapter capability manifest before enabling them.

Continue with the platform support matrix and capability declarations before selecting destinations.

Reply and retry scope

Set replyTo on a target when destinations reply to different native posts or comments. A request-level replyTo applies to all its targets. Every reply reference must use the selected target’s account, backend, and platform; mismatches fail preparation before dispatch.

Idempotency fingerprints include target content, options, reply references, and schedules. Changing any of these under a previously claimed logical key produces an idempotency conflict. Provider request keys also include the tenant scope, so shared accounts do not collapse two tenants’ independent publication intentions into one provider request.

The client’s concurrency limit applies to each backend across overlapping reads and writes on that client. A queued cancellation does not dispatch a write. Native adapter access bypasses client coordination and must be managed explicitly by the application.

Native scheduling on direct adapters

A direct adapter accepts schedule only when the platform stores the post and publishes it at the requested time. The SDK does not delay a request itself. Only the YouTube adapter supports this today; see schedule a video. The other direct adapters reject schedule during preparation, before any network call, and declare posts.schedule in their capability manifests with the reason.

These sources were checked on 2026-09-24. Because these adapters never create a scheduled post, they do not implement posts.cancelScheduled. To publish later on these platforms, run the publish from your own durable job runner, or use a hosted backend that schedules on your behalf.

Cancel a schedule or remove content

Use the operation that matches the resource you intend to change. These methods authorize the reference’s account before network access and check backend ownership before writing.

Direct adapters also implement posts.removeFromPlatform for X, Threads, Bluesky, LinkedIn, YouTube, and Instagram with Facebook Login. They delete the native post with the connected account credentials. The direct TikTok adapter does not implement it.

The direct YouTube adapter implements posts.cancelScheduled for videos uploaded with schedule. It clears the scheduled publish time and leaves the video uploaded and private; it never deletes the video. See YouTube for the quota cost and scope.

On Zernio, native removal needs the backend record ID preserved in post.native.backendRecordId. A native post ID alone cannot identify that provider record. Post for Me does not advertise native removal because its record deletion endpoint does not establish that it removes live platform content.

A record shared by multiple destinations is rejected by these mutations. The client will not change another account’s schedule or post as a side effect. Schedule cancellation requires a future schedule; once submission is due or underway, reconcile its delivery. The provider controls races between cancellation and dispatch. Cancellation never proves that an already dispatched native post was removed.

Mutations are sent once. A lost response raises ambiguous_outcome with reconcile-first; inspect the backend before repeating the operation.

Edit a published post

Editing is a native operation because each platform changes a different part of a post. The direct adapters declare posts.update as follows:

Edits are sent once, like the other mutations. See each platform page for eligibility rules and sources.