Social media posting APIs: what each platform actually lets you publish

A social media API is an HTTP interface a platform publishes so software can act on an account without driving a browser. In practice the term collapses three distinct things. A posting API, sometimes listed as a social media post API, writes content: it creates a post, uploads media, replies to a thread. A social media analytics API reads performance data back for content you already own. A social media listening API, sometimes sold as a social media monitoring API, reads other people's public content at volume.

Platforms grant these separately and price them separately. LinkedIn treats publishing and page analytics as different use cases inside the same access request form; Meta reviews publishing permissions and insights permissions independently. Approval for one is not approval for another, and listening access is the hardest of the three to get.

This page covers the first kind only. When someone asks for an API for social media, writing a post is almost always what they mean, and it is the only one of the three a small team can realistically ship in a week.

Every row below was read on the platform's own developer documentation. The column that matters most is the third one: the publish call is a few lines in any language, and the approval hoop is what decides whether your integration ships this month or next quarter.

One pattern runs through the whole table. The platforms with the largest audiences gate public publishing behind a human reviewing a recording of your product. The ones with no review at all are the newer or federated networks, plus the two chat surfaces where a webhook URL is the entire authentication story.

If you want to automate LinkedIn posts, this is the request. LinkedIn's Posts API replaces the older ugcPosts API, and a text post is a single POST to https://api.linkedin.com/rest/posts. The two headers people forget are Linkedin-Version, a version string in YYYYMM format, and X-Restli-Protocol-Version, which must be 2.0.0. A successful create returns 201 with the post URN in the x-restli-id response header.

Change the author URN to urn:li:person:{id} and the required scope becomes w_member_social instead of w_organization_social. That one field is the whole difference between posting as a company page and posting as a person.

Note what the request does not do. LinkedIn's documentation states the Posts API does not scrape URLs for article posts, so if you want a link preview you set the thumbnail, title and description yourself after uploading the image through the Images API. Every platform has one of these: a thing you assumed was automatic that turns out to be your job.

X is the clearest case of a platform that changed. It no longer sells fixed Basic and Pro subscription tiers; the X API now runs on pay-per-usage, where you buy credits up front in the Developer Console and they are deducted per request. Writes are billed individually, and the pricing page lists a materially higher per-request price for a post containing a URL than for one without. Release announcements contain a link by definition, so price the expensive row.

Meta is the opposite shape. Calling the Graph API, the Instagram content-publishing endpoints or the Threads API costs nothing. The cost is App Review. Under Standard Access a permission can only be requested from people who already hold a role on your app, which is fine for an internal tool and useless for a product. Advanced Access, the level any real user needs, requires business verification and a review in which Meta tests your app.

YouTube is free but metered: Google's quota documentation gives a project 100 videos.insert calls per day, 100 search.list calls per day, and 10,000 units per day shared across everything else. Reddit is free to call with a registered OAuth client and a descriptive User-Agent, but read Reddit's developer terms before you ship anything commercial on it.

Every platform runs its own OAuth flow with its own scope names, its own consent screen and its own token lifetime. You will store a different credential shape per platform, refresh some of them on a schedule, and handle the case where a user revokes access silently. Threads adds a wrinkle most do not: permission grants expire after 90 days for accounts with public profiles, so a working integration stops working without anyone touching it.

Media is rarely one call. Instagram and Threads both use a two-step container model: you POST the media to create a container, wait for the platform to finish processing it, then POST again to publish that container. Meta's Threads documentation recommends waiting roughly 30 seconds between the two. LinkedIn splits it further, with separate Images, Videos and Documents APIs that each return a URN you then reference from the post body. None of this is difficult; all of it is state you now own.

Rate limits are not even shaped the same way. X documents POST /2/tweets at 10,000 per 24 hours per app and 100 per 15 minutes per user, so you can exhaust the user window while the app window is barely touched. Instagram and Threads count published posts against a rolling 24-hour window. YouTube counts uploads against a daily call allocation instead. A single retry policy will not fit all four.

Then there is app review, which is the only item on this list that a better architecture cannot help with. LinkedIn requires a Development tier approval, then a Standard tier request with a downloadable screen recording demonstrating a user completing OAuth and posting through your product. Meta tests your app itself and rejects the submission if reviewers cannot reach it. Both are measured in weeks, and both must be redone when your functionality changes materially.

To post to multiple social media accounts at once for free, start with the platforms that have no gatekeeper: Discord, Slack, Bluesky and Mastodon. Discord's Execute Webhook endpoint explicitly does not require authentication, because the token is part of the URL, and Slack's incoming webhooks work the same way once an app carrying the incoming-webhook scope is installed. Both take a JSON body over a plain POST, and the only real difference is the field name: Discord reads content, Slack reads text.

Bluesky and Mastodon extend the same idea to public social, and neither has a review process. Bluesky's AT Protocol exposes procedures under a /xrpc/ path; a client calls com.atproto.server.createSession with an account identifier and a password, where an app password is the supported credential for third-party clients. Mastodon requires registering an application on each server with POST /api/v1/apps, then posting with the write:statuses scope. Five servers means five registrations.

What this free path does not get you is the audience most products care about. LinkedIn, Instagram and Facebook are not on it, and no amount of engineering skips their review. Treat the zero-review set as the first release of your integration, not the whole of it.

Build direct when you need one or two platforms and the account you post to is your own. A Bluesky adapter is an afternoon; a Discord webhook is ten minutes. You keep platform-specific features, you pay nothing extra, and there is no vendor between you and the API when something breaks. If your entire requirement is announcing releases into your own Discord server, stop reading and go write it.

Buy a layer when the count goes up and the accounts belong to other people. This is where social media automation stops being a feature you wrote and starts being infrastructure you maintain. At three or four platforms the recurring work is no longer the adapters; it is token refresh, expiring grants, App Review resubmissions when Meta changes a requirement, and per-platform rate-limit handling. That is a standing claim on someone's week, forever. The cost of buying is a dependency you did not write and a ceiling on platform-specific features you did not anticipate needing.

The middle answer, which is often the right one: build direct for the one or two platforms that matter most to your product and where you want native control, and take a layer for the long tail you would otherwise never get round to.

The trigger is a GitHub event. A release, a tag, a merged pull request or a deployment arrives through the Ship 2 Post GitHub App, a rule decides on semver, branch, path, label and repo scope whether it qualifies, and the pipeline drafts channel-native variants. Those go to a review queue for one-click approval, or publish without a stop if you switch that channel to autonomous mode. If what you need is to publish arbitrary copy from your own scheduler, this is the wrong tool and the platform APIs above are the right ones.

What Ship 2 Post does expose is a bearer-authenticated /v1 surface with a published OpenAPI 3.1 document at GET /v1/openapi.json. API access requires the Growth plan or higher; a key on the Free or Starter plan gets 403 plan_required on every call. Keys are workspace-scoped and scope-checked on each request.

The limits, stated plainly, because they are the ones that would waste your afternoon. There is no POST /v1/drafts, so a draft cannot be created without a release signal behind it. There is no scheduling feature of any kind. There is no public retry endpoint: re-publishing a variant whose previous attempt failed returns 409 conflict, and retry lives in the in-app queue instead. Outbound webhooks are not HMAC-signed, so a receiver has no signature header to verify and must treat the webhook URL as the secret and de-duplicate on the idempotency key in the payload.

There are 14 destinations. Eleven are native platform integrations: LinkedIn, X, Threads, Bluesky, Reddit, Facebook, Instagram, YouTube, Mastodon, Discord and Slack. The other three, Hacker News, Substack and custom webhook, share one outbound-webhook adapter that POSTs to a URL you supply. Of the eleven, only Bluesky and Mastodon connect headlessly; the rest need a browser OAuth round trip once, for exactly the reasons the table above describes.