Building social media publishing in-house vs using a unified API

It starts with one platform

Nobody sets out to build a social media publishing platform. They set out to add a feature.

“Let users share to Instagram.” That is the ticket. It sounds like a week of work. You look at the API docs, write an OAuth flow, upload an image, create a post. Done.

Then the next ticket arrives. “Can we add LinkedIn?” Then X. Then Threads. Then Facebook. Then TikTok and YouTube. Each one is “just another integration.” Each one is its own engineering project.

By the time you support four or five platforms, you are not maintaining a feature. You are maintaining infrastructure — authentication systems, media upload pipelines, error handling layers, token refresh logic, format validation rules. Infrastructure that has nothing to do with your actual product.

This is the story we hear from every team that has tried it. And it is the story we lived ourselves when building 64ads.

The true cost, broken down

The cost of building social media publishing in-house is not the initial integration. It is everything that comes after. Here is what each layer actually requires.

1. OAuth: seven different authentication systems

Every platform uses OAuth. None of them agree on how.

X requires OAuth 2.0 with PKCE. Access tokens expire after 2 hours. Refresh tokens are single-use — every refresh returns a new one and invalidates the old. If you fail to store the new token, the session is permanently lost. The user must re-authenticate.

Facebook, Instagram, and Threads use Meta’s OAuth. There are no refresh tokens. Instead, you exchange a short-lived token (1–2 hours) for a long-lived token (60 days) via a separate API call. Long-lived tokens can be re-exchanged once per day, but only if they are at least 24 hours old. Page tokens derived from a long-lived user token never expire — but only if you follow the derivation chain correctly.

LinkedIn issues 60-day access tokens. Refresh tokens exist but are only available to approved partners. Most developers get no programmatic refresh at all. When the token expires, the user must reconnect. Every request requires a Linkedin-Version header and X-Restli-Protocol-Version: 2.0.0, or it fails silently.

TikTok gives you 24-hour access tokens with 365-day refresh tokens. Straightforward — until the app audit process rejects your integration for the third time because your UX does not match their guidelines.

YouTube uses Google OAuth 2.0 with 1-hour access tokens and long-lived refresh tokens, but only if you include access_type=offline in the initial request. Unverified apps are limited to 100 users and can only upload private videos.

Pinterest issues 30-day access tokens with 365-day refresh tokens. The flow itself is standard, but the token must be refreshed before expiration — there is no grace period.

That is seven OAuth implementations, seven token storage schemas, seven refresh strategies, seven error handling paths for expired or revoked tokens. Each one must be built, tested, and maintained separately.

Engineering cost: 2–4 weeks for the initial implementation across all platforms. Ongoing maintenance every time a platform changes its OAuth behavior — which happens at least a few times per year.

2. App review: the gate you did not budget for

Before your integrations work in production, every platform must approve your app.

Meta (Facebook, Instagram, Threads) requires individual permission review for each scope. You submit your app, record a screencast demonstrating how each permission is used, write a detailed description of your use case, and wait. Reviews take days to weeks. Rejections are common, often for reasons that are not immediately obvious. Each resubmission restarts the clock.

If you need instagram_content_publish, pages_manage_posts, and threads_manage_posts, that is three separate screencast submissions with three separate review cycles. Some scopes require a verified business account. Some require agreeing to additional platform policies.

TikTok has a multi-round audit process. Your app must pass a UX compliance review, a functionality review, and a security review. Auditors test your integration manually. If your “Connect TikTok” button does not meet their UX standards, you are rejected and must resubmit.

YouTube (Google) requires OAuth scope verification for sensitive and restricted scopes. youtube.upload is a sensitive scope. Verification requires a detailed description, a privacy policy, a homepage, and sometimes a third-party security assessment. Unverified apps have a 100-user cap and can only upload private videos.

LinkedIn requires product-level approval. To access the Posts API, you apply for the “Share on LinkedIn” product. Approval is not guaranteed and can take weeks.

Engineering cost: 2–6 weeks elapsed time, spread across multiple review cycles. Not continuous engineering work, but continuous attention — checking review status, responding to feedback, resubmitting with changes. This time is pure overhead. It does not produce product features.

3. Media uploads: seven distinct protocols

This is where the complexity compounds. Every platform handles media uploads differently. Not slightly differently — fundamentally differently.

X uses a three-step chunked upload flow. Initialize with file metadata, append binary chunks (max 5 MB each), finalize. For video, you then poll for processing status before attaching the media to a tweet. Four API calls minimum for a single video.

Instagram and Threads use a container model with URL pull. You do not upload a file. You provide a publicly accessible URL and the platform fetches the media. For Instagram, you create a container, poll until processing completes, then publish in a second call. Threads adds a mandatory 30-second wait between container creation and publishing.

Facebook uses its own Resumable Upload API. You create an upload session, POST the binary with an offset header, receive a file handle, and attach that handle to a post. Different endpoints for photos, videos, reels, and stories.

LinkedIn requires chunked uploads with ETag tracking. You register the upload, receive a list of upload URLs, PUT each chunk to its assigned URL, collect the ETag from each response, and finalize. Missing an ETag means the upload fails silently.

TikTok supports two patterns: URL pull or chunked file upload with Content-Range headers. Before publishing, you must query the creator info endpoint to get available privacy levels — using one the creator has not enabled causes a rejection. Photo posts and video posts use different endpoints entirely.

YouTube uses Google’s resumable upload protocol. Initiate a session with video metadata, receive an upload URI, PUT the binary to that URI. Video metadata (title, description, privacy) goes in the initiation request, not with the video data.

Pinterest uses a direct upload or URL-based approach, with separate flows for standard pins and video pins.

A cross-platform media upload layer is not a wrapper around similar endpoints. It is seven distinct upload implementations, each with its own binary handling, its own chunking strategy, its own processing model, and its own error semantics.

Engineering cost: 3–6 weeks for the initial implementation. This is the single largest line item. Each platform’s upload protocol is its own project.

4. Format validation and content constraints

Every platform enforces different rules about what you can publish.

Your publishing layer must validate content against every platform’s constraints before sending anything. A 600-character post works on most platforms but gets rejected by X (free tier) and Threads. A PNG image works everywhere except Instagram, which only accepts JPEG. A video over 512 MB works on LinkedIn but not on X.

You either validate upfront and return clear errors, or you let the platform reject the request and parse their error responses — which are inconsistent and often unhelpful.

Engineering cost: 1–2 weeks. Ongoing maintenance as platforms change their limits — which they do without much notice.

5. Error handling and partial success

When you publish to one platform, error handling is straightforward. The request succeeds or it fails. When you publish to seven platforms simultaneously, the failure model changes entirely.

Three platforms succeed. One returns a rate limit error. One times out. One returns a 200 with an error nested in the response body. One accepts the request but fails during asynchronous processing and reports the failure minutes later.

This is not an edge case. This is the normal case.

Your system must handle:

• Synchronous errors — 4xx and 5xx responses at request time
• Asynchronous errors — failures that occur during processing after a 200 response (Instagram container processing, TikTok video processing, YouTube upload processing)
• Rate limit errors — each platform has its own rate limiting scheme, with different limits, different windows, and different headers
• Ambiguous errors — responses where you cannot tell whether the content was published or not (timeout after the request was sent but before the response arrived)
• Per-platform outcomes — tracking which platforms succeeded and which failed for the same publish intent
• Retry decisions — determining which failures are safe to retry without creating duplicate posts

A naive implementation treats all failures the same. A production implementation handles each error type differently, per platform, with retry policies that reflect the actual behavior of each API.

Engineering cost: 2–3 weeks for robust error handling. This is the kind of work that feels like it should take a day but does not, because every platform’s error semantics are different.

6. Ongoing maintenance: the cost that never ends

The initial build is the smaller cost. Maintenance is the larger one.

API deprecations. Platforms deprecate and version their APIs regularly. X moved from v1.1 to v2. Meta versions their Graph API every few months. LinkedIn introduced the Posts API to replace the UGC Posts API. Each deprecation requires code changes, testing, and deployment — on the platform’s timeline, not yours.

Breaking changes. Sometimes announced, sometimes not. A field name changes. A required parameter is added. A response format shifts. An endpoint starts returning a different error code. Your integration breaks in production, and the first sign is failed publishes.

Rate limit changes. Platforms adjust rate limits based on your app’s tier, usage patterns, or policy changes. What worked last month may start returning 429s this month. Your system needs monitoring and alerting for rate limit changes you did not expect.

New platform requirements. Meta may add a new compliance requirement for apps using instagram_content_publish. TikTok may change its audit criteria. Google may require a new security assessment. These appear as emails that demand attention on someone else’s schedule.

Token revocations. Users change passwords, disconnect apps, or revoke access. Platforms revoke tokens for policy violations. Your system needs to detect revocation, notify users, and handle reconnection gracefully.

New features. A platform adds carousel support, or Threads launches, or Pinterest adds video pins. Your customers want support for these. Each addition is a new integration project inside your existing system.

Engineering cost: 1–2 engineers spending 10–20% of their time on social media integration maintenance. Not building features. Not shipping product. Maintaining plumbing. Indefinitely.

The total cost of building in-house

Adding up the components:

Initial build: 10–21 weeks of engineering time, plus 2–6 weeks of elapsed time waiting for app reviews.

Annual maintenance: 9–17 weeks of engineering time — roughly 2–4 months of a developer’s year, every year, for as long as you maintain the integrations.

This is not hypothetical. This is what teams report after they have built it. The initial estimate is always “a few weeks.” The reality is always months, and the maintenance never stops.

What a unified API looks like

Here is the same operation through Postproxy. One call, all platforms:

curl -X POST "https://api.postproxy.dev/api/posts" \
     -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "post": {
         "body": "We just shipped a new feature that changes everything about onboarding."
       },
       "profiles": ["twitter", "instagram", "facebook", "linkedin", "threads", "tiktok", "youtube"],
       "media": ["https://your-storage.com/announcement.mp4"]
     }'

That is the entire publishing implementation. One endpoint. One authentication mechanism (your Postproxy API key). One media format (a URL). One response with per-platform outcomes.

Everything described in the sections above — seven OAuth flows, seven media upload protocols, format validation, error handling, rate limiting, token refresh, app review — happens inside Postproxy. Your system never touches it.

What you skip

OAuth. Postproxy has already implemented and maintains every OAuth flow. Your users connect their social accounts through Postproxy’s connection flow, which handles token exchange, refresh, and re-authentication per platform. You store a Postproxy API key, not seven platform tokens.

App review. Postproxy’s app is already approved on every platform. Your product does not need separate approval from Meta, TikTok, Google, LinkedIn, or Pinterest. You skip weeks of review cycles entirely.

Media uploads. You provide a publicly accessible URL. Postproxy downloads the file and uploads it to each platform using the correct protocol — chunked for X, container for Instagram, resumable for YouTube, ETag-tracked for LinkedIn. Your system handles one format: a URL.

Format validation. Postproxy validates content against each platform’s constraints before uploading. If something does not meet a platform’s requirements, you get a clear error before any network calls happen.

Error handling. Per-platform outcomes come back in a structured response. You know exactly what published, what failed, and why. Partial success is explicit, not hidden.

Maintenance. When X changes its API, Postproxy updates. When Meta deprecates a Graph API version, Postproxy migrates. When LinkedIn adds a new required header, Postproxy adds it. Your integration does not change. The contract between your system and Postproxy stays the same while the contract between Postproxy and the platforms evolves.

What you still own

Postproxy does not replace everything. You still own:

• Content creation. Postproxy does not generate posts, write captions, or choose images. What to publish is your decision.
• Scheduling logic. When to publish is your decision. You can use cron, workflow engines, CMS webhooks, or manual triggers.
• Approval workflows. Whether content should go live is your decision. Postproxy supports drafts and human-in-the-loop patterns, but the approval logic lives in your system.
• Monitoring and alerting. You still need to check post status and handle failures in your workflow. Postproxy tells you what happened — what you do with that information is up to you.

The division is clean: your system handles intent, Postproxy handles execution.

When building in-house makes sense

There are cases where direct integration is the right call:

Single platform. If you only publish to X and will never support another platform, the integration is manageable. One OAuth flow, one upload protocol, one set of error handling. The complexity multiplier that makes multi-platform hard does not apply.

Deep platform-specific features. If you need features that go beyond publishing — reading DMs, managing comments, running ad campaigns, accessing platform-specific analytics — a unified publishing API will not cover those. Direct integration gives you access to the full platform API surface.

Regulatory or compliance requirements. If your organization requires that no third party touches social media credentials, direct integration is the only option. This is rare but real in some regulated industries.

You are building a social media tool. If social media integration is your core product — if you are building the next Buffer or Hootsuite — then owning the platform layer is a strategic choice, not a build-vs-buy decision.

For everyone else — teams where social media publishing is a feature, not the product — the math rarely favors building it yourself.

The decision

The question is not whether you can build social media publishing in-house. You can. Teams do it every day.

The question is whether you should spend 3–5 months of engineering time building and maintaining infrastructure that is not your product, and then spend another 2–4 months every year keeping it running.

One API call replaces all of that. The content still comes from your system. The timing still follows your logic. The approval still reflects your workflow. The only thing that changes is that the execution layer — the part that deals with seven different OAuth flows, seven different upload protocols, and seven different sets of API quirks — is handled by a system built specifically for that job.

That is the tradeoff. Engineering months against an API call. Building plumbing against building product.

Connect your accounts and start publishing through the Postproxy API.