Social publishing API · REST + MCP

Looking to wire up social? Start with one publishing API.

One API key. One publishing contract. Per-destination results for eligible connected accounts. We handle connection setup, supported token refresh, provider-aware media paths, and recorded outcomes—so your app or agent can ship the feature.

Start free — no card → Run the quickstart

First Free key: 7 days across every currently available publishing destination, up to 300 publishes. Then 2 platform types and 100 attempts monthly. No auto-charge.

POST /v1/publish
one request
{
  "text": "Shipping today.",
  "targets": ["bluesky", "twitter", "facebook"]
}
BS Blueskyjob receipt · job_81c… ✓ published
X Xjob receipt · job_81d… ✓ published
f Facebook Pagejob receipt · job_81e… ✓ published
requested: 3 succeeded: 3 failed: 0

The solved problem

One publishing API for provider-specific work.

Every provider has its own authorization, media rules, error shapes, rate limits, and review process. We turn that integration tax into one bounded contract.

OAuth

Stop building a token-management product.

Launch provider authorization from one connection flow and keep credentials behind the publishing boundary.

Provider differences

Send one shape. Get one normalized result model.

Fan out to as many as 20 connected targets while preserving provider-specific detail where it matters.

Operational truth

Know what actually happened.

Every target returns its own success or failure result. Durable jobs, posts, logs, and provider receipts stay visible.

Agent control

Give agents a narrow tool, not your social credentials.

The local MCP gateway exposes health, connections, providers, publishing, and receipt lookup through an API-key boundary.

Direct integrationsOne OAuth app and callback maze per provider
With Social FanoutOne connection layer and one API-key contract
Provider-specific media, retries, and error handling
Provider-aware adapters behind one publish request
“Did it post?” scattered across multiple dashboards
Per-target results, durable jobs, posts, and receipts
Your team maintains every integration forever
New approved destinations strengthen the same contract

First publishing check

Connect two destinations. Validate once. Publish when ready.

The guided setup gives you an API key, walks through provider connections, and lets you verify the exact request before a live post.

1 Create a free keyNo card and no automatic charge.
2 Connect destinationsUse the guided connection setup in the dashboard.
3 Validate the requestKeep dryRun true for the first check.
4 Publish deliberatelyAfter approval, set dryRun: false and use a new key for this live attempt.
shell · multi-target dry run REST 
# after connecting Bluesky and X
curl https://socialfanout.com/v1/publish \
  -H "x-api-key: $SOCIAL_FANOUT_KEY" \
  -H "content-type: application/json" \
  -H "idempotency-key: launch-check-001" \
  -d '{
    "text": "Shipping today.",
    "targets": ["bluesky", "twitter"],
    "dryRun": true
  }'

The validation key is only for this dry run. After approving the exact content and accounts, use a distinct live-attempt key; never reuse the validation key to publish. Keep the live key and body unchanged while checking its outcome. Bare target names resolve through stored connections. You can also pass target objects to pin an account, Page, Board, subreddit, or provider-specific setting. A fan-out call accepts up to 20 targets.

Your agent can use the same publishing boundary.

Launch the local stdio MCP server with your Social Fanout key. Or import the GPT Action into ChatGPT where Actions are available. Both call the hosted REST API underneath; neither turns the current local MCP server into a hosted remote MCP endpoint.

fanout_health fanout_list_providers fanout_list_connections fanout_publish_post fanout_get_job
Choose an agent setup →

Publishing V1 truth

What can publish now—and what is still waiting.

This is a publishing matrix. Comments, replies, and messages are separate provider scopes and are never used to make a publishing destination look more complete than it is.

Destination Publishing V1 Current boundary
X Available 100 text-only X posts per API key monthly; link-bearing posts use prepaid Link Packs.
LinkedIn members Available LinkedIn member publishing is available for eligible connected profiles, with periodic reconnect when LinkedIn does not issue refresh access.
LinkedIn Pages Administered Pages LinkedIn Page publishing works for Pages administered by the connected member under Development Tier, and refreshable Page connections renew on publish; Standard Tier review is pending for unrestricted customer Page access. LinkedIn uses the dashboard, REST API, or local MCP; the current ChatGPT Action excludes it.
TikTok Available Content Posting is approved; comments are a separate review lane.
Facebook Pages Available Page publishing is approved; comments and messages are separate scopes.
Bluesky Available Native publishing through a connected account.
Reddit Available Publishing is bounded by the authorized account and target community.
Discord Available Publishing through a configured, authorized destination.
Email Available Email delivery is exposed as a destination in the same publishing contract.
Instagram Available Standalone image/Reel publishing is approved for eligible Professional accounts through Business Login for Instagram.
Threads Available Text and image publishing is approved for eligible connected accounts.
Pinterest Limited Standard access and production OAuth/public-Board lookup are verified; final publishing verification remains pending. Publishing is immediate-only.
YouTube Limited Required Google/YouTube reviews and publishing verification remain pending.

Availability depends on provider approval, requested scopes, account permissions, and upstream API health. Pending destinations do not enter the live publishing lane until approval and production verification are complete.

Receipts, not promises

The result is part of the product.

A request being accepted is not the same as a provider publishing it. Social Fanout keeps those states distinct.

1

Request receipt

A cached successful response can be returned for the same key. Concurrent requests, partial fanout, and cache failures can still duplicate posts. Check receipts before retrying.

2

Per-target outcome

One failed provider does not erase the truth about the targets that succeeded. Each result remains explicit.

3

Durable follow-through

Jobs, posts, logs, and provider receipts give your team or agent somewhere concrete to inspect and recover.

Prove it before you buy it

Start with the integration. Upgrade after the value moment.

No cold-sales loop and no card wall. Build the proof, inspect the receipts, then decide whether the working lane belongs in production.

Free proof

Free

$0 no card

  • One-time 7-day all-current-destination trial
  • Up to 300 publishes during the trial
  • Then 2 platform types and 100 attempts monthly
  • Guided key, connection, and first-publish setup
Start the free proof →

No automatic charge. Keep the Free key after the trial.

Founder rate · while active

Builder

$9.99 / month

  • Builder entitlement and 3,000 monthly publishes
  • Every currently available publishing destination
  • REST API plus local MCP gateway
  • Pending destinations unlock after approval and production verification
Start Builder at $9.99 →

Founder price stays locked while the subscription remains active. X link-bearing posts use separate Link Pack credits.

Developer FAQ

The questions we would ask before wiring this in.

Can one API request publish to multiple destinations?

Yes. POST /v1/publish accepts up to 20 targets and returns a result for every target plus requested, succeeded, and failed counts. Each target must be connected and available for publishing.

Can we build our own calendar or workflow?

Yes. The REST API and MCP tools are the product contract. The dashboard agenda and Post Flight Deck are optional reference clients for review, scheduling, receipts, and recovery.

Is the MCP server remote?

No. It is a local stdio gateway launched by your agent client. It uses your Social Fanout API key to call the hosted REST API.

Do pending providers count as available?

No. Not available, In review, Sandbox, and Limited are distinct statuses. Pending destinations unlock only after provider approval and a production verification pass.

How does X usage work?

Each API key includes 100 text-only X posts per UTC month. X posts containing links use prepaid Link Packs: 40 linked posts for $10. Failed provider calls do not consume the allowance or a credit.

Ship the proof

Give us one publish request. Keep the receipts.

Start free, connect two destinations, and validate the exact contract your app or agent will use. When the integration fits your workflow, choose Builder for $9.99 a month while that discounted subscription stays active.

Start free — no card → Read the full quickstart