Platforms Overview

RelayAPI's 22 connected publishing platforms, connection models, and capability boundaries.

Supported publishers

RelayAPI's runtime registry and database schema support 22 connected publishing platforms. Scheduling is handled by RelayAPI for every publisher; provider capabilities and connection requirements still differ.

“Supported” means a concrete publisher is registered and the platform identity can be represented by the current database schema. It does not override provider app review, product tier, regional availability, account type, media policy, or permissions. Check the platform page before relying on a specific content type.

Target selectors and provider identities

Create a connection first. Each targets entry may be a RelayAPI account ID, a platform key, or a workspace ID:

• acc_... selects one exact connected account.
• A platform key such as twitter expands to every active, authorized Twitter account in the post's workspace boundary.
• ws_... expands to every active, authorized account in that workspace.

Overlapping selectors are de-duplicated before publishing. Prefer account IDs when a post must reach one exact provider identity; use the broader selectors only when their fan-out is intentional.

const post = await client.posts.create({
  content: 'Release 2.0 is live.',
  targets: ['acc_x_example', 'acc_linkedin_example'],
  scheduled_at: 'now',
  target_options: {
    twitter: {
      content: 'Release 2.0 is live. 🚀',
    },
    linkedin: {
      content: 'We have released version 2.0. Read the full changelog…',
    },
  },
});

curl -X POST https://api.relayapi.dev/v1/posts \
  -H "Authorization: Bearer $RELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: release-2-announcement" \
  -d '{
    "content": "Release 2.0 is live.",
    "targets": ["acc_x_example", "acc_linkedin_example"],
    "scheduled_at": "now",
    "target_options": {
      "twitter": {"content": "Release 2.0 is live. 🚀"},
      "linkedin": {"content": "We have released version 2.0."}
    }
  }'

The post's workspace and every resolved account must be mutually authorized. Organization-scoped accounts are visible to credentials with at least one workspace grant; zero-grant credentials see no operational accounts.

Selector expansion does not let publisher options retarget a provider credential. For example, Snapchat always uses the selected Public Profile, Telegram always uses the challenged chat, and Slack/Discord always use the connected webhook destination. TikTok pull-mode media is restricted to the verified URL prefixes snapshotted when that account connected.

Connection classes

• OAuth — RelayAPI redirects the user and stores encrypted access/refresh credentials. Some platforms require a second provider-identity selection.
• Dynamic OAuth — Mastodon registers an OAuth client on the chosen safe public instance and pins that origin to the account.
• Credential connection — RelayAPI stores an encrypted app password, API key, Twilio credential, or webhook after the strongest validation the provider offers. Slack has no non-mutating webhook probe, so its first publish is the activation check.
• Managed bot — Telegram uses a short-lived challenge and verifies both the human administrator and the managed bot's posting permission.

See Connecting Accounts for the exact flows and credential lifecycle.

Published edits and interactions

RelayAPI exposes provider-backed text edits for published X, Facebook, Discord, and Reddit targets, plus a narrower capability matrix for message/comment editing, read receipts, mentions, moderation, likes, votes, and ratings. These are durable mutations with required idempotency keys; unsupported platform/action pairs fail before provider I/O. See Published Edits and Social Actions.

Native analytics

RelayAPI currently exposes native account analytics for Facebook, Instagram, Twitter/X, LinkedIn, YouTube, TikTok, Pinterest, Threads, Google Business, and WhatsApp when the account type and scopes allow them. Other publishers can still participate in stored cross-platform post analytics when RelayAPI has collected snapshots, but they do not gain a live provider adapter merely because publishing is supported.

See Analytics for endpoint, workspace, cache, and pagination behavior.

Provider outcomes

Provider acknowledgement is not always the same as publication or delivery:

• Snapchat Spotlight can remain in moderation.
• Twilio SMS can be accepted, sent, delivered, partially failed, or unknown per recipient.
• WhatsApp's signed sent callback remains nonterminal; only delivered/read or failed terminalizes an outbound target.
• Slack incoming webhooks return ok without a message ID, so they cannot be reconciled or deleted through this integration.
• Telegram returns a Message (or one Message per media-group item) but has no later delivery/read lifecycle in this publisher; RelayAPI persists every album message ID for unpublish.

Use one RelayAPI Idempotency-Key per logical mutation, retain it across retries, and follow Error Handling whenever the provider outcome is uncertain.

Unpublish support

POST /v1/posts/{id}/unpublish attempts provider deletion independently for each published target. RelayAPI currently implements provider delete for Twitter/X, Facebook, LinkedIn, Reddit, Pinterest, Threads, YouTube, Bluesky, Google Business, Telegram, Mastodon, and Discord.

Instagram is intentionally not on that list: the current official Instagram API does not document deletion of published Instagram Media. Slack incoming webhooks also provide no message ID suitable for deletion. Targets on Instagram, Slack, TikTok, Snapchat, WhatsApp, SMS, and the newsletter publishers remain published when no supported provider-delete contract exists; RelayAPI returns a per-target error instead of pretending the remote object was removed.