Someone asks you to add "share to social" to your product. You look at it and think: seven or eight REST calls, a week of work.
I want to lay out what is actually behind that estimate, network by network, with current numbers. Not to talk you out of building it. Some of you should. But the cost is concentrated in places that do not show up in the estimate, and almost none of it is the HTTP call.
Everything below was verified in July 2026. Half of it will be wrong within a year, which is itself part of the point.
The gates, network by network
The HTTP requests are genuinely easy. Getting permission to make them is not.
Meta (Facebook Pages and Instagram)
Instagram publishing needs a Professional account, Business or Creator. Personal accounts have zero API access. That account has to be linked to a Facebook Page, because the permissions flow through the Page.
Then you need App Review for two permissions, instagram_business_basic and instagram_business_content_publish. App Review means Business Verification, a working demo, and a screen recording of your app performing each use case. Budget two to four weeks per submission, and expect more than one submission.
Publishing itself is two calls: POST a media container to /{ig-user-id}/media, then publish it with /{ig-user-id}/media_publish. That part takes an afternoon.
There are two very different doors here.
w_member_social is the easy one. It is in the Consumer tier, it is free, and it lets an authenticated member post on their own behalf. If your feature is "let a user share to their own LinkedIn", you are mostly fine.
Posting to Company Pages is the Community Management API, and it is not open to individual developers. You need a registered company, a verified LinkedIn Page, and a two-tier review: Development Tier first with limited call volume, then Standard Tier, which requires a screencast demonstrating every use case in your access request. There is a vetting survey you have to complete within 21 days of it being triggered.
Plan for a three to six month approval cycle. That is not engineering time. That is calendar time where your feature does not ship.
TikTok
TikTok's Content Posting API has a gate that surprises people because it does not block you, it silently degrades you.
Content posted by an unaudited client is forced to private visibility. Not the privacy setting your user chose during OAuth. Private, always, regardless. Your integration will look like it works in every test you run, and then your users' posts will be invisible.
Before audit you can create up to five sandboxes per app, each shared with up to ten TikTok accounts, and everything posted from a sandbox is also forced private. That is the gate working as designed: build and test freely, ship publicly only after review.
There is an escape hatch worth knowing about. Inbox upload mode drops the finished video into the creator's TikTok drafts for a human to publish. It needs no audit, and honestly it is the right design for a lot of content pipelines anyway.
YouTube
Credit where it is due: this one got better. videos.insert used to cost roughly 1,600 quota units per call against a default 10,000 units per day, which capped you at six uploads a day. In December 2025 Google quietly cut it to roughly 100 units, so the default project now handles around 100 uploads a day.
The catch is that you cannot buy your way past the ceiling. There is no paid commercial tier for the YouTube Data API. If you need more, you file a quota extension request through Cloud Console and wait. Money is not an option, which is unusual and worth knowing before you design around it.
X (Twitter)
X changed the deal in 2026. Pay-per-use credit pricing arrived for new developers on 6 February, rates were revised again on 20 April, and there is no free tier. Basic and Pro are closed to new signups and legacy-only for existing subscribers.
Current rates: $0.015 to create a post, and $0.20 if that post contains a URL.
Read the link premium again. It is more than thirteen times the base rate, and "post a link" is exactly what a social scheduling feature does all day. A thousand link posts a month is $200 in API charges alone, against $15 for the same volume without URLs.
Threads
Free, and the friction is Meta App Review again for production access.
The publishing caps are per profile in a rolling 24 hour window: 250 posts, 1,000 replies, 100 deletions. Replies do not count against the post cap. Carousels, text and image posts all count equally. There is a GET /{threads-user-id}/threads_publishing_limit endpoint so you can check usage before you hit the wall, and you should call it.
Google Business Profile
Every new Google Cloud project starts with zero quota for the Business Profile APIs. Not a small quota. Zero. The API is free and there is no per-call billing, but you cannot make a single call until you are approved.
Approval requires a formal access request, a legitimate use case (your own locations or your clients'), a verified profile that has been active for 60 or more days, and a real business website. Reviews take around 14 days. You will know you are through when your quota reads 300 QPM.
Quota increases go through a separate contact form, and they get denied if your average usage is under 50% of your current limit. So you cannot pre-scale. You have to grow into it.
The part nobody budgets for
Suppose you clear every gate. Now you have the actual hard problem, and it is not authentication.
Each network has its own rules for what a valid post looks like. Caption length, hashtag limits, how many images, whether you can mix images and video, aspect ratios, resolution bounds, frame rate, duration, file size. They are all different, and they change without much warning.
When you publish the same content to several networks at once, what you can actually send is the intersection of all their rules. That intersection is much narrower than any single network, and it is not obvious until you compute it.
Here is a real example. This is the merged constraint set for one media post going to all eight networks above at the same time:
{
"caption": { "maxLength": 280, "maxHashTags": 30 },
"media": {
"maxOverall": 1,
"maxImages": 0,
"maxVideos": 1,
"canMixOverall": false,
"specs": {
"video": {
"maxSizeBytes": 75000000,
"fps": { "min": 23, "max": 60 },
"duration": { "min": 3, "max": 30 },
"ratio": { "min": 0.5625, "max": 1 }
}
}
}
}
Read that carefully, because it is more brutal than it looks. Posting to all eight at once gets you one video, no images at all, 30 seconds maximum, and a 280 character caption.
The caption is X's ceiling. The 30 seconds is the tightest video window in the set. And images disappear completely, because YouTube accepts video only, so its presence deletes every image-based option for the other seven.
Drop YouTube and the picture changes entirely:
{
"caption": { "maxLength": 280 },
"media": { "maxOverall": 4, "maxImages": 4, "maxVideos": 1, "canMixOverall": false }
}
Four images come back. One network, added or removed, silently redefines what all the others can carry. That is the part you cannot see by reading the platform docs side by side.
Reels are stricter still. Across Instagram, TikTok, YouTube and Facebook you get exactly one video, no images, 3 to 90 seconds, 24 to 60fps, and a hard 9:16 ratio with no tolerance at all:
{
"media": {
"maxVideos": 1,
"maxImages": 0,
"specs": {
"video": {
"duration": { "min": 3, "max": 90 },
"ratio": { "min": 0.5625, "max": 0.5625 },
"resolution": { "width": [540, 1080], "height": [960, 1920] }
}
}
}
}
Encoding this once is a decent chunk of work. Keeping it correct is the actual cost, because these values drift and nobody sends you a changelog. You find out when a customer's post fails.
The ongoing tax
Beyond the gates and the constraints, there is a permanent maintenance line you are signing up for:
- Token lifecycle. Every network expires tokens differently. You need refresh flows, re-auth prompts, and a way to tell a user that their Instagram connection quietly died three days ago.
- Breaking changes. Meta versions its Graph API and deprecates old versions on a schedule. LinkedIn versions monthly. You will spend time on migrations that deliver zero new value.
- Support burden. "Why didn't my post go out?" becomes a category of ticket. The answer is usually a token, a quota, or a media constraint, and diagnosing which is on you.
- Re-review. Change your use case and you may go back through App Review.
None of that is hard. All of it is forever.
The other option
We are Swonkie, a social media management platform, and we maintain all of the above so our own product works. We expose it to developers at swonkie.dev as a publishing and measurement API, and more recently as a remote MCP server.
One call goes to every connected network. The constraint sets above are not illustrations, they came out of our posts_rules_get endpoint, which you can call before you build a payload so you know what will pass. There is a validate step that runs the real publish rules and tells you what would fail and why, before anything goes out.
The MCP server matters if you are building anything agent-shaped. It is remote and stateless, so there is nothing to install:
{
"mcpServers": {
"swonkie": {
"type": "http",
"url": "https://mcp.swonkie.dev/mcp?apiId=YOUR_API_ID&apiKey=YOUR_API_KEY"
}
}
}
Point Claude or Cursor at that and it can list your connected profiles, check the rules for a post type, draft it, validate it, route it through approval, publish it, and pull the analytics back. 27 tools, 11 resources, 8 prompts.
There is also Andie, our image generation, which takes a text prompt and returns a production-ready social image already uploaded to your media library, usable directly as post media.
Who this is genuinely for: your own brand, or an agency managing many client accounts. One workspace holds many connected profiles, so 50 brands under one roof is fine. What it does not do today is multi-tenant SaaS where each of your end customers brings their own accounts under their own billing. That is a reseller arrangement, not a self-serve API model, and I would rather say so here than have you discover it in week three.
API and MCP docs: swonkie.dev and docs.swonkie.dev/mcp-server.
If you build it yourself
Genuinely fine, and sometimes right. Two suggestions:
Start the approvals before you write code. LinkedIn Community Management and Google Business Profile are measured in months, not sprints, and they are pure calendar time. Every week you delay filing is a week added to the end.
Build the constraint table before the publishing logic. The temptation is to get one network posting, then add the rest. That order buries the hard problem until late, and the hard problem is not the posting, it is knowing what will be rejected before you send it.
Sources checked July 2026. Platform terms change often, so verify anything here against the official docs before you plan around it: Meta, LinkedIn, TikTok, YouTube, X, Google Business Profile.
Top comments (1)
What era we are living, great article, one more tool to help with my automations.