Create a post

Create a new post to publish or schedule across multiple social media platforms simultaneously. A post might mean something different depending on the context and the platform - for example, a single X post, a multi-thread X post, a LinkedIn post, or an Instagram Reel or Story. Posts use a container model where each container holds content for one segment (e.g., individual tweets in an X thread, or carousel items). Specify target platforms via the accounts array, referencing each connected account by its id from GET /v1/social-accounts (preferred) or its exact username - network names (e.g. x, linkedin) and nicknames are not identifiers and do not resolve. The request is rejected with 400 only when none of the supplied identifiers resolve, so an entry matching nothing alongside one that matches is dropped silently. Provide the post body either as a single content string or as a containers array of { content, media } objects - one of the two is required. Attach media by adding media objects to a container, each { url, filename } where url is the publicly accessible URL returned by the confirm-upload step (see Media API); media is not referenced by id. Include scheduledAt (ISO 8601 format, e.g. 2025-06-01T12:00:00Z) to schedule the post for future publishing, or omit it to publish immediately. Platform-specific options (e.g., TikTok privacy settings, YouTube categories, Pinterest board IDs) are provided as top-level keys named after the network (tiktok, youtube, instagram, threads, google_business, pinterest, linkedin, facebook, vimeo, reddit, x, bluesky) - not nested under any wrapper object. Every one of those blocks also accepts content: text published on that network instead of the shared body, so one post can carry a professional LinkedIn version, a casual Instagram caption and a short X version while the top-level content remains the fallback for the rest. Only the root text is overridden - media, first comments and thread replies stay shared, and two accounts on the same network get the same override. The response echoes these back nested under networkOverrideConfiguration (e.g. tiktokConfiguration), so the request and response shapes for platform config differ by design. Unrecognised top-level keys are ignored and reported in the response warnings array. Threads limits each container to 500 characters, so a request targeting a Threads account - on its own or cross-posted alongside other networks - is rejected with 400 if any container is longer; when threads.content is set, that override is checked in place of the shared body, which is how a long LinkedIn post cross-posts to Threads. Managed-key YouTube uploads are admitted at execution time from a shared paced daily pool; scheduling never reserves capacity. A denied YouTube destination fails independently and its existing error string (also in webhook results) contains a stable reason code (release_pending, org_limit_reached, daily_limit_reached, provider_quota_exhausted, or quota_unavailable) and an ISO 8601 retryAt when known. retryAt estimates earliest eligibility for a capacity release, organization-cap relaxation, or next Pacific quota day; it is not a reservation. Retry manually. If another destination already published, create a new YouTube-only post targeting the failed account because partially published posts cannot be edited or rescheduled. BYOK bypasses the shared pool; dispatched attempts are not refunded on failure. Google Business EVENT and OFFER posts require an event title, startDate, startTime, endDate and endTime. CALL buttons omit callToAction.url; other action types require it. Google ignores callToAction on OFFER posts. Facebook videoCoverUrl accepts a public HTTP(S) JPEG cover up to 10,000,000 bytes for exactly one video, including Reels. Stories cannot have covers. The image is validated before video upload; applying the cover after publication is best-effort and rejection leaves the video published.