Build vs. Buy: Maintaining 10 Social Platform Integrations Yourself

Sooner or later, most products that touch social media get the same request: "Can we post this to LinkedIn too? And Instagram? And TikTok?" The first integration looks like an afternoon of work. The tenth looks very different.

This post is an honest comparison of building those integrations yourself versus using a unified API like Relaycast. We sell the second option, so take our view with that in mind, but there are real cases where building is the right call, and we will say so.

What "an integration" actually includes

Posting a text update through one network's API is genuinely easy. Running a production integration is not, because the work is mostly everything around that one call.

Developer apps and review

Most networks require you to register a developer app, describe how you will use their API, and in many cases pass an app review or audit before you can post on behalf of other users. Each process has its own forms, screencasts, policies and timelines, and permissions you were granted can be narrowed later.

OAuth, ten different ways

Every OAuth provider has its own quirks: PKCE or not, refresh tokens or not, short-lived tokens that must be exchanged for long-lived ones, tokens that can only be refreshed after a certain age, page-level tokens derived from user tokens. You need a refresh strategy for each, a lock so two workers do not refresh the same account at once, and a way to tell users their account needs reconnecting when access is revoked.

Media handling

This is where most of the time goes. Some networks fetch media from a public URL; others want you to upload bytes, sometimes in chunks, sometimes through a resumable session. Some process video asynchronously, so you have to poll until it is ready before you can publish. Size limits, format restrictions (for example, JPEG-only images) and aspect ratio rules differ per network and per post type.

Content rules

Character limits are counted differently (characters, UTF-16 code units, graphemes). Some networks cap hashtags or mentions. Some post types require exactly one video, others allow carousels within a range. If you do not validate up front, these become failed jobs instead of helpful error messages.

Platform options

Each network has its own settings: video titles and visibility, reply controls, content warnings, branded content disclosures, collaborators, boards, call-to-action buttons. Every option needs a field in your UI, validation, and mapping to the API.

Failures and retries

Networks time out, rate-limit and return transient errors. You need to know which errors are worth retrying, retry with backoff, avoid double-posting when a request succeeded but the response was lost, and record a clear reason when something finally fails.

Ongoing change

APIs get new versions, deprecate endpoints and change policies. Each integration needs someone who notices and updates it. Multiply by ten.

The case for building it yourself

Building in-house is a reasonable choice when:

• You only need one or two networks, and they are core to your product. Owning that integration deeply can be worth it.
• You need an endpoint a unified API does not cover, such as a niche feature of one network's API.
• You have strict requirements about where tokens live and cannot allow a third party to hold them, even encrypted.
• Publishing is your product. If social publishing is the thing you sell, the integrations are your core competency, not a cost.

In those cases the maintenance burden is the price of control, and it may be a fair price.

The case for a unified API

A unified API makes sense when social publishing is a feature of your product rather than the product itself, and you want breadth without a team dedicated to keeping ten integrations alive.

With Relaycast, the work described above collapses into one request shape:

{
  "content": "Our spring release is live.",
  "media": [{ "url": "https://cdn.example.com/release.mp4", "type": "video" }],
  "targets": [
    { "accountId": "YOUTUBE_ACCOUNT_ID", "options": { "title": "Spring release", "visibility": "public" } },
    { "accountId": "TIKTOK_ACCOUNT_ID", "options": { "privacyLevel": "PUBLIC_TO_EVERYONE" } },
    { "accountId": "LINKEDIN_ACCOUNT_ID" }
  ],
  "publishNow": true
}

What you get in exchange:

• Validation before queueing. Each target is checked against its platform's rules when you create the post. Problems come back as a 400 grouped by account, before anything is published or charged.
• Independent results. Each target is its own job with its own status, external URL and error. One network failing does not affect the others. See why per-platform results matter.
• Retries and idempotency. Transient errors are retried with exponential backoff. An Idempotency-Key header makes your own retries safe.
• Token lifecycle. Tokens are stored encrypted and refreshed before they expire. Revoked accounts are marked as needing reconnection.
• Notifications. Email or signed webhooks when posts are scheduled, published, partially failed or failed.
• Your own OAuth apps if you want them. With bring-your-own-key apps, the consent screen shows your app's name, while Relaycast handles the plumbing.

The trade-offs of buying

Buying is not free of downsides, and you should weigh them:

• Coverage lag. When a network launches a new feature, a unified API has to add support before you can use it.
• A dependency. Your publishing now relies on another service's availability.
• Cost per post. Relaycast charges one credit per target. At very high volume, compare that against the engineering time you would otherwise spend. See pricing.
• Abstraction limits. A shared request shape covers the common ground well, and platform options cover a lot of the rest, but not every corner of every network's API.

A simple way to decide

Ask three questions:

1. How many networks do you need in the next year? One or two leans towards building; four or more leans towards buying.
2. Is publishing your product or a feature? Products justify owning the integrations; features usually do not.
3. Who will maintain it? If the honest answer is "whoever is free when it breaks", factor that in.

If you want to try the unified route, create an account and read the getting started guide. The Playground lets you see validation for every platform before you write any code, which is a quick way to find out whether the abstraction fits your use case.