How many separate integrations does it take to post everywhere?
The honest answer: one per platform, each with its own auth model, rate limits, and media rules. A look at what "post everywhere" actually requires, platform by platform.
By André LugOne per platform — there is no shortcut where a single OAuth flow or request shape covers Instagram, LinkedIn, and X at once. Covering the 12 publishing platforms PostGate supports means five genuinely different authorization mechanisms (three OAuth 2.0 flavors, OAuth 1.0a, an app password, and a static bot token), and five of the twelve gate you behind a review or audit first.
The honest answer is: one per platform. There is no shortcut where a single OAuth flow or a single request shape covers Instagram, LinkedIn, and X at once — each platform runs its own authorization model, its own rate limits, and its own media rules, and none of that is shared infrastructure you get to reuse. "Post everywhere" sounds like one feature. It is actually N separate integrations, where N is however many networks your customers care about.
PostGate currently supports 12 real publishing platforms in production, listed below with what actually differs between them. The point of this table isn't just the count — it's that the differences are multiplicative, not additive: adding a platform doesn't just add its own integration work, it adds another set of edge cases your shared retry, queue, and status logic has to correctly handle without assuming what worked for the last platform will work for this one.
PostGate handles OAuth, publishing and delivery evidence for every network through one API. Start free or read the docs.
How do the twelve platforms differ?
| Platform | Auth model | Token lifecycle | Approval gate |
|---|---|---|---|
| OAuth 2.0 (Meta) | Long-lived token, ~60-day refresh cycle | Meta App Review, per-permission | |
| Facebook Pages | OAuth 2.0 (Meta) | Shares Meta OAuth; separate permission from Instagram | Meta App Review, reviewed independently of Instagram |
| Threads | OAuth 2.0 (Meta) | Refresh endpoint distinct from Instagram's, same family | Meta App Review |
| OAuth 2.0 | Standard member token forces periodic reconnection | Community Management API vetting: company verification, development tier, standard-tier screencast review | |
| TikTok | OAuth 2.0 | Access token on a 24-hour cycle | Audit required for audited-client posting caps and public visibility |
| YouTube | OAuth 2.0 (Google) | Standard Google refresh token | Google Cloud quota increase request, separate from content review |
| OAuth 2.0 | Refresh token, standard cycle | Trial access has restricted write scopes until approved for production | |
| X | OAuth 1.0a | Tokens don't expire — but also never silently self-repair when revoked | No content review; access gated by pay-per-use credit pricing instead |
| Bluesky | App password (AT Protocol) | No OAuth expiry cycle in the current app-password model | None |
| Mastodon | OAuth 2.0, per-instance app registration | Instance-dependent; varies by server operator | None, but each instance is a separate app registration |
| Telegram | Bot API token | Static bot token, no refresh cycle | None |
| Google Business Profile | OAuth 2.0 (Google) | Standard Google refresh token | Google Business Profile API access request |
Three OAuth 2.0 flavors, one OAuth 1.0a holdout, one app-password model, and one static bot token — that's five genuinely different authorization mechanisms across twelve platforms, before you get to the differences in what each token actually expires on, if it expires at all. Five of the twelve gate you behind some form of review or audit before you can post to real accounts at normal limits; seven don't. None of that maps cleanly onto a single "connect account" abstraction without real per-platform branching logic underneath it.
Why is it multiplicative, not additive?
The trap in estimating this is assuming the tenth platform costs the same as the first, since "you've done this before." In practice the shared infrastructure — job queue, token encryption, idempotency — is genuinely reusable and does get cheaper per platform after the first one. But the platform-specific surface doesn't shrink: each new platform still needs its own media validation rules, its own error-code taxonomy, its own retry-safety analysis (is this specific error retryable, or will retrying double-post?), and its own delivery-status story (webhook-backed, like Instagram, versus polling-only, like several others). Twelve platforms means twelve of each of those, not one built once and reused eleven more times.
We put real ranges on what that costs in our build-cost estimate, and worked through when it's actually worth doing yourself versus not in our build-vs-buy framework.
What does "post everywhere" look like as one integration?
This is the gap PostGate is built to close: one create-post endpoint across all twelve platforms above, with hosted OAuth connections that absorb each provider's specific consent flow, a single idempotency contract instead of twelve retry-safety analyses, and a uniform aggregate-plus-per-target delivery status model regardless of whether the underlying platform pushes a webhook or requires polling. The twelve-platform complexity in the table above doesn't disappear — it just moves from your codebase to ours.
Frequently asked questions
Do the Meta platforms share one integration?
Only partially. Instagram, Facebook Pages, and Threads all use Meta's OAuth 2.0 family, but each has its own permission and its own review: Facebook Page publishing is reviewed independently of Instagram — passing one does not fast-track the other — and Threads has a refresh endpoint distinct from Instagram's. None of it maps onto a single connect-account abstraction without real per-platform branching underneath.
Which social platforms require approval before you can post via API?
Five of the twelve gate you behind a review or audit: Instagram, Facebook Pages, and Threads all require Meta App Review; LinkedIn runs a Community Management API vetting flow with company verification and a standard-tier screencast review; TikTok requires an audit for normal posting caps and public visibility. Separately, YouTube gates on a Google Cloud quota increase request, Pinterest restricts write scopes during trial access, and X has no content review but gates access with pay-per-use credit pricing. Bluesky, Mastodon, and Telegram have no approval gate.
Does each new platform integration get cheaper after the first one?
The shared infrastructure — job queue, token encryption, idempotency — is genuinely reusable and does get cheaper per platform. But the platform-specific surface never shrinks: each new platform needs its own media validation rules, its own error-code taxonomy, its own retry-safety analysis (is this error retryable, or will retrying double-post?), and its own delivery-status story. Twelve platforms means twelve of each of those, which is why the cost is multiplicative, not additive.
How do token lifecycles differ across social platforms?
Widely. Instagram uses a long-lived token on a roughly 60-day refresh cycle; TikTok's access token runs a 24-hour cycle; LinkedIn's member token forces periodic reconnection; X's OAuth 1.0a tokens never expire but also never silently self-repair when revoked; Bluesky's app-password model has no OAuth expiry at all; and Telegram uses a static bot token with no refresh cycle. Each of those is a separate refresh contract your integration has to implement correctly.
