Create post

Create a post, and optionally publish it in the same request. A post published immediately (publishNow: true) comes back with platformPostUrl in the response.

content is optional in four cases:

• media is attached
• all platforms have customContent
• every platform entry is an X Article (platformSpecificData.article)
• every platform entry is a LinkedIn text-free reshare (platformSpecificData.reshareUrl with no text)

See each platform's schema for media constraints.

Scheduling

Pick one of:

• scheduledFor: publish at the scheduled time
• publishNow: true: publish synchronously, inside this request
• queuedFromProfile: publish in the profile's next queue slot

With none of them and isDraft unset, the post is saved as a draft. platforms is required unless the post is a draft.

Precedence: isDraft: true wins over publishNow and scheduledFor (the post is saved, never published), and publishNow: true wins over scheduledFor. A scheduledFor already in the past is not rejected: the post is published synchronously in the same request, exactly like publishNow.

Idempotency

Two layers of duplicate-protection apply, so safe-to-retry callers (network blips, n8n / Zapier retries, etc.) don't accidentally double-post.

1. Same-request idempotency (5-minute window). Pass an x-request-id header to mark a logical request. If a second request arrives with the same x-request-id while the first is in-flight (or within ~5 minutes of completion), we return HTTP 200 with the original post in the existingPost field, and no new post is created.

The official Zernio SDKs auto-generate a unique x-request-id per call. On a generic HTTP client (curl, n8n's HTTP node, Zapier, custom code), either:

• Set a unique x-request-id per logical call (recommended, UUIDv4 is fine)
• Or omit the header, and we'll treat each request as new

Common pitfall: if your workflow tool uses a single execution-level request ID and reuses it across multiple HTTP nodes (e.g. one ID for the whole run, shared across 6 different platform calls), every call after the first will look like a retry of the first and return its post. Generate a fresh ID per node.

2. Content-hash dedup (24-hour window). Independently, we hash (platform, accountId, content + media URLs) and reject duplicates within 24 hours with HTTP 409. This catches genuine "same content posted twice to the same account" cases regardless of x-request-id. The response carries error, accountId, platform, and existingPostId so you can find the original.

To intentionally re-post identical content within 24h, change something (the caption, the media, the account), because the dedup is keyed on the full content fingerprint.

Order: same-x-request-id retries (200) are checked first; if no idempotency match, the content-hash dedup (409) runs.

{  "dryRun": true,  "canPublish": true,  "tiktok": [    {      "accountId": "string",      "canPublish": true,      "alreadyPostedToday": true,      "reason": "string"    }  ]}