One API vs building each social integration yourself

If your product needs to publish to one or two social networks and you care about their platform-specific features, building the integrations yourself is often the right call. If you need five or ten networks and mostly want "post this, on time, everywhere", the work is less about the posting call and more about approvals, tokens, media processing and upkeep, which is where a unified API earns its place. This post lays out both sides so you can decide with your eyes open.

What "just call their API" really involves

The publish request itself is rarely the hard part. The work sits around it.

Approval programmes before you can go live

Most networks let you build against a test account freely, then gate real users behind a review.

• Meta (Instagram, Facebook, Threads). App Review is required once people without a role on your app will use it. Instagram publishing needs Advanced or Standard Access to the content publish permissions, and Meta says apps needing advanced access may also need Business Verification, a separate process. Threads publishing uses its own threads_content_publish permission.
• TikTok. Until your client passes an audit, the Content Posting API restricts everything you post to private viewing.
• YouTube. Videos uploaded through videos.insert from unverified API projects created after 28 July 2020 are locked to private until the project passes a compliance audit.
• LinkedIn. The Community Management API is a vetted product with a Development tier and a Standard tier. Moving to Standard means submitting a screencast of every use case you applied for.
• Pinterest. On Trial access, Pins and Boards you create are sandbox entities that only their creator can see. Standard access needs a video showing your OAuth flow.
• Google Business Profile. You apply for API access through a contact form, and the profile you manage must have been verified and active for 60+ days. An unapproved project sits at 0 queries per minute.
• X. Access is paid. As of September 2026, X's docs describe pay-per-usage pricing with no subscriptions, with credits bought upfront. X says rates are subject to change and the Developer Console has the current ones, so check there rather than trusting any figure in a blog post, including this one.

Each review has its own forms, screencasts and timelines, and a rejection usually means fixing something and resubmitting. You do this once per network, and again when you add permissions.

Tokens that expire on different clocks

Every network runs OAuth a little differently, and lifetimes vary.

So you need a background job that refreshes tokens before they lapse, per network, plus a way to notice when a refresh fails and ask the user to reconnect. LinkedIn is explicit that it can revoke tokens at any time for technical or policy reasons and expects you to fall back to the normal sign-in flow. Every network has some version of this.

Media is asynchronous

Posting a video is not one request. On Instagram you create a media container, then publish it, and in between you poll the container's status_code until it reads FINISHED (or ERROR, or EXPIRED if you waited more than 24 hours). TikTok hands you a publish_id and you check the post status while it processes. Each network has its own upload flow, its own states and its own failure modes, so your worker needs a small state machine per network.

Content rules differ too: text limits, how many images a post may carry, whether video is required, whether images and video can mix. You either validate all of that up front or learn about it from a rejection after the fact.

Rate limits and quotas

Limits are per network and often per account:

• Instagram accounts are capped at 100 API-published posts in a rolling 24 hours.
• Threads profiles are capped at 250 API-published posts in a rolling 24 hours.
• YouTube gives new projects 10,000 units a day for most endpoints. videos.insert now has its own bucket of 100 calls a day at 1 unit each. Older guides quote a much higher per-upload cost, so check the current page before you plan capacity. More needs a quota extension request.
• LinkedIn's Development tier allows 500 requests per app and 100 per member by default.

Your scheduler has to respect all of these, back off when told to, and retry safely without creating duplicates.

Versions and deprecations

APIs move. Meta says each Graph API version is usable for at least two years, and stops working two years after the next version ships. LinkedIn's marketing APIs are versioned monthly, and the Community Management docs currently carry a notice that the October 2025 version sunsets on 15 October 2026. None of this is unreasonable, but across ten networks it adds up to a steady stream of migration work that someone has to own.

When building it yourself is the right call

Building in-house makes sense when:

• You only need one or two networks. The fixed costs above are per network. For a single integration, they may be a sensible investment.
• You need deep, platform-specific features. Ads, advanced analytics, shopping tags, story stickers, community features. A unified API is built around what networks have in common, so niche features may be missing or arrive late.
• You need something no unified API exposes. If it's core to your product, own it.
• You want control of the app identity. With your own app, users see your name on the consent screen, you hold the relationship with the platform, and nobody else's review status or policy standing affects yours.

When a unified API makes sense

A unified API tends to fit when:

• You need many networks and the common core of publishing. Text, images, video, scheduling, and a clear success or failure per network.
• Social posting supports your product rather than being the product. Your engineers' time goes further on what makes you different.
• You want one error model. One request shape and one kind of error to handle, instead of ten.

The costs of a unified API

It is not free, and you should weigh these honestly:

• Another vendor dependency. Their outage is your outage. Look at how they report status and what happens to scheduled posts during an incident.
• Lowest-common-denominator features. You get what the provider has chosen to expose. Check the specific fields and options you need before you commit.
• You still follow each network's rules. A unified API doesn't exempt you from platform policies, content rules or consent requirements. TikTok, for example, expects specific consent UI to be shown to the person posting.
• Pricing. You pay a subscription on top of any costs the networks themselves charge. Compare it with the engineering time you would actually spend, not an optimistic estimate.
• App identity. Depending on the provider, users may authorise an app that isn't branded as yours.

A side-by-side view

Where postpeg fits

postpeg is a unified API for the common case: one POST /v1/posts to publish or schedule across X, Instagram, Facebook, LinkedIn, TikTok, YouTube, Threads, Pinterest, Bluesky and Google Business through their official platform APIs. Each post is validated against every target network before anything is sent, transient failures are retried with backoff, an Idempotency-Key header makes your own retries safe, and expired logins surface as reconnect_required with hosted OAuth links to fix them (Bluesky connects with a handle and app password). If that matches what you need, start with the docs, see the social media posting API overview, or check pricing.