Skip to content
Social SDK Cloud, the hosted SDK, is taking early-access signups.Join the list
Social SDK megaphone markSocial SDK
Esc
↑↓navigate↵open⌘Jpreview
On this page

Content

Understand shared content, per-target platform options, declared formats, and strict local preparation in Social SDK publish requests.

A publication carries one shared content object to every selected target, plus per-target options for what platforms require individually. Preparation validates all of it locally before any network call.

Shared content, per-target options

Content holds the text, media list, and link. Target options hold platform-specific requirements: YouTube’s title, visibility, and audience flags, TikTok’s consent and privacy choices, Bluesky’s languages and mentions. The shape keeps one intent reusable across destinations without pretending platforms want identical input.

A target can also carry content that replaces shared fields for that target only. Each of text, media, and link you set on the target replaces the shared field of the same name; fields you leave out are inherited.

await social.posts.publish({
  targets: [
    {
      account: youtubeAccount,
      options: { title: "Release", visibility: "private", madeForKids: false },
    },
    // X gets shorter text and keeps the shared video.
    { account: xAccount, content: { text: "Release day. Notes in the thread." } },
  ],
  content: { text: "Release day: what changed and why.", media: [video] },
});

Formats are declared per route

Text, image, video, carousel, and document are the content formats adapters declare, and each capability declaration lists the formats it accepts. Ordered multi-post threads go through posts.publishSequence rather than a format; see publishing. The same platform can differ by route: check the capability matrix rather than assuming.

Validation is platform-real

Preparation applies the rules each adapter implements, which follow the platform where it documents a limit and are narrower where the adapter supports less: X’s weighted 280-character counting, Bluesky’s grapheme lengths and byte-offset mentions, the Bluesky adapter’s four-image or one-video posts, the Threads adapter’s carousels of up to twenty items, LinkedIn’s 2 to 20 image multi-image posts, YouTube’s title bounds, and the TikTok adapter’s PULL_FROM_URL transfer from verified HTTPS origins. These are the current adapter caps, not a statement that the platform API offers nothing else. Failures return structured issues naming the field and rule, before the platform is contacted.

Nothing is transformed silently

Adapters do not crop images, truncate text, convert formats, or drop unsupported fields to force a request through. Unsupported input fails preparation loudly, and richer platform features stay reachable through native access instead of being approximated. See the publish content guide for the full request lifecycle.

Last updated on October 5, 2026