Choosing a Social Media Posting API

Search for a social media posting API and you get three kinds of page: vendor homepages asserting their own superiority, listicles whose entire evaluation apparatus is a column of starting prices next to a column of platform counts, and encyclopaedic explainers about the native platform APIs. None of them hands you something you can actually score.

That is the gap this page fills. Below is a nine-question rubric where every question is answerable in an afternoon from a vendor's own public documentation, with no sales call and no trial, then six named vendors scored against it, including OctoSpark. We sell in this category, so treat our scoring as a starting point and re-run the questions yourself. The questions are the durable part; the answers change every quarter.

The two numbers every comparison page leads with, starting price and platform count, are the two least predictive numbers in the decision. Pricing shape moves your bill by an order of magnitude depending on your account-to-post ratio, and a platform count says nothing about whether you can post a carousel, a Reel, a Story or a first comment.

What a unified posting API buys you, and who should skip one

A unified API sells you one request shape across seven or more platforms, plus the OAuth token lifecycle, plus the queue that turns "publish this" into platform-specific multi-step upload sequences. Instagram alone is a container-create then container-publish dance where media must be hosted on a publicly accessible server at the time of the attempt, publishing supports JPEG only, carousels cap at 10 items, and the account must be an Instagram professional account holding instagram_business_basic and instagram_business_content_publish, per Meta's content publishing docs. That is one platform, and it is not the hard one.

Skip the category in three cases. If you publish to exactly one platform, integrate that platform directly and skip the abstraction tax. If posting is a side feature of an internal tool used only by people who hold a role on your own developer app, you avoid a large chunk of app review and direct integration gets cheap fast. And if your content is unusually format-specific (shoppable video, ad creative, platform-native effects), unified APIs expose the intersection of platform features rather than the union, and you will fight the abstraction.

Everybody else, particularly agencies, schedulers, AI-agent products and anything multi-tenant, is buying maintenance rather than code. Our builder's guide to publishing programmatically covers the native endpoints underneath if you want that grounding first.

The nine questions

Score each from 0 to 3 against the vendor's public docs. If you cannot find the answer in the docs at all, that is a 0, not a blank. Undocumented behavior is behavior you will discover in production.

1. What shape is the pricing (per-post, per-profile, per-account, flat, or one-time license), and where does it cross over at my volume?
2. Which formats does it support per platform, not which platforms does it list?
3. Does it deliver publish results by webhook, with a documented ack window, retry schedule and idempotency key?
4. Is there a sandbox or test mode I can point CI at without publishing real content?
5. Whose developer app holds the OAuth tokens, mine or the vendor's?
6. What does exit cost: can I export tokens, or does every user re-consent?
7. What are the token-refresh mechanics, and what happens when a token dies at 3am?
8. How does it surface platform rate limits, and does it retry safely or duplicate?
9. What is the support and status reality: public status page, incident history, response time in writing?

Question 1: pricing shape beats price

The cheapest vendor inverts depending on your ratio of connected accounts to monthly posts. Five billing shapes exist, with genuinely different slopes:

• Per-post: linear in volume, flat in accounts.
• Per-profile: you pay per customer, brand or location, and a profile can hold many connected accounts. Stepped in tenants, flat in volume.
• Per-account: linear in connected social accounts.
• Flat: a plan fee with soft limits. Zero slope until a ceiling, then a cliff.
• One-time license: self-hosted, you own the compute and the platform relationships.

Ayrshare publishes the clearest ladder in the category, so it makes the best worked example. A profile is one customer, brand or location: a single customer connected to Pinterest, Bluesky, YouTube, Reddit, X and TikTok is still one profile. Premium is $149 per month for one profile and up to 13 social accounts; Launch is $299 for up to 10 profiles; Business is $599 in the 31 to 300 profile band, with extra profiles at $8.99 each for 31 to 100 and $3.49 for 101 to 500. Run two real shapes against a generic per-post competitor at $0.01 per publish.

Case A, the AI-agent product: 5 accounts under one brand, 50,000 posts per month. Per-profile: $149. Per-post: $500. Per-profile wins by 3.4x, and the gap widens as you grow. The break-even is back-of-envelope arithmetic: a $149 profile beats $0.01-per-post at 14,900 posts per profile per month.

Case B, the reseller: 200 low-volume tenants, 3 accounts each, 20 posts each, so 4,000 posts total. Reading the ladder literally: $599 base, plus 70 profiles at $8.99, plus 100 at $3.49, landing near $1,577 per month. Per-post: $40 plus a base plan. That is an inversion of roughly 30x the other way. Against an $8.99 incremental profile, per-post at $0.01 only wins below 899 posts per profile per month.

The honest caveat: per-profile looks expensive in Case B because you are comparing it against posts when what you are buying is tenant plumbing, isolated token stores, per-customer analytics and connection UIs. If you would build those anyway, add your engineering cost to the per-post column before declaring a winner. Verify current numbers on each pricing page; ladders move.

Do the crossover math before the demo, not after. Two vendors whose starting prices differ by $10 can differ by 30x at your actual volume, in either direction.

Question 2: "20 platforms" is a logo count

Upload-Post advertises 22 platforms, a list including Nostr, Lemmy, Dev.to and Listmonk. Zernio says 16. Post for Me says 9. These numbers are not comparable, because they count different things and none tells you what you can publish.

The question that matters is format coverage per platform. For each platform you care about, demand a yes or no on: single image, multi-image carousel, short-form video, long-form video, Stories, first comment, thread or reply chains, native scheduling versus vendor-side queue, alt text, location tagging and user tagging.

"Supports Instagram" can mean any subset of that list, and platform constraints sit underneath the vendor's. Instagram caps accounts at 100 API-published posts per rolling 24 hours, a carousel counting as one. Threads caps at 250 posts per 24 hours with a limit derived from impressions, so a brand-new profile with no reach gets a tiny budget. TikTok's Direct Post typically caps around 15 posts per day per creator. No vendor can sell you past these, and one that does not surface them in error messages lets you find out by silent failure.

Our comparison of scheduling tools by use case is a useful sanity check on what "full support" looks like in a mature product. On our side, multi-platform publishing documents per-format coverage rather than a headline number.

Question 3: the 200 that isn't a publish

This is the most underserved topic in the category. Publishing is asynchronous on every platform: your 200 OK means accepted, not published.

The failure mode is specific and common. You POST a video to TikTok, get a success response, mark the post published in your UI, and the platform rejects it forty seconds later for a media constraint. Without a callback your database is permanently wrong, and your customer finds out from their audience.

Ayrshare's webhook documentation is the best public specification of this contract, worth reading even if you never buy from them, because it tells you what to demand from everyone else. The receiving server must return a 2xx within 15 seconds. On a non-2xx or timeout it retries twice, after 5 seconds and again 30 seconds later, reusing the same hookId. The docs state plainly that occasional duplicates are normal.

That contract dictates your implementation, and the implementation is the same regardless of vendor:

1. Ack first, process later. Write the raw payload to a queue and return 2xx immediately. Anything inline risks blowing the 15-second budget and triggering a retry.
2. Claim the idempotency key atomically. Insert the hookId into a table with a unique constraint; if the insert conflicts, drop the message. "Check then write" loses this race, because two deliveries 5 seconds apart both read "not seen" before either writes.
3. Treat the callback as the source of truth. A post row moves to published only when a callback says so, never when the POST returns.
4. Handle the callback you never get. Reconcile anything stuck in pending past a threshold. Webhook delivery is best-effort everywhere.

Score a 0 if the vendor documents no ack window, no retry schedule and no stable per-event ID. You cannot write a correct integration against undocumented retry behavior.

Question 4: can you build CI against it?

Ask whether there is a sandbox or dry-run mode that validates payloads and returns realistic responses without publishing. Native platforms are hostile to testing by design. Content posted by unaudited TikTok clients is restricted to private viewing, and unaudited clients can allow only five users to post per 24 hours, per TikTok's content sharing guidelines. Pinterest's trial tier keeps pins off the public web. YouTube is sharpest: the Data API grants 10,000 units per day overall, but videos.insert sits in a separate bucket of 100 quota per day, so a project gets roughly 100 uploads daily regardless of general quota. Burn that on CI and production uploads stop.

With no sandbox you have two options, both costly. Posting real content to throwaway accounts is realistic and catches format rejections mocks never will, but consumes rate limit and, on TikTok, your five-user unaudited cap. Mocking the vendor entirely is fast and free and verifies nothing: your contract tests pass while the real API returns a shape you have never seen.

The workable middle ground is mocking the vendor for unit and integration tests, plus one nightly smoke test per platform against a real throwaway account that publishes and then deletes. Budget the rate limit for it explicitly.

Questions 5 and 6: whose app is it, and what does exit cost?

These travel together, because the first answer determines the second. In shared-credential mode, the vendor's developer app holds the OAuth relationship and your customers consent to the vendor's app. In white-label mode, you obtain platform developer approval yourself and the vendor operates against your credentials. Post for Me states this unusually plainly: quickstart mode uses its own platform credentials with no approval needed, while white-labelling requires your own approval.

Shared credentials get you live this week. The costs are real and mostly invisible until they bite:

• Blast radius. A platform action against the vendor's app affects every customer at once, including yours, and you have no independent standing to appeal.
• Branding. Your customers see the vendor's name on the consent screen.
• Verification. Under Meta's business verification rules, apps requesting advanced access and apps allowing other businesses to access their data must complete business verification; without it, app users from other businesses cannot grant those permissions. In white-label mode that paperwork lands on your desk, which is a genuine advantage of shared credentials for small teams.

Exit cost falls out directly, and nobody puts it in a pricing table. If the vendor's app holds the tokens, they are scoped to that app and cannot be transferred. Migrating means every user re-consents. For 25 clients that is 25 awkward emails; for 5,000 connected accounts it is a re-onboarding campaign with completion well under 100%, and the accounts that never reconnect are churn you caused.

So add one line to your evaluation: what percentage of my users would I have to re-authenticate to leave? If the answer is 100%, price the switching cost in now, while you still have leverage. Ask every shared-credential vendor in writing whether a white-label upgrade path exists that preserves connections, and what it costs. Our agency operating model guide covers the client-communication side.

Questions 7 to 9: auth, limits and support

On auth, find out whether the vendor refreshes long-lived tokens automatically and how you are told when a refresh fails: a webhook event is good, a silent 401 on your next publish is bad. On rate limits, ask whether it surfaces the platform's remaining budget or just proxies errors, and whether retries are idempotent (a retry that re-posts is worse than a failure). LinkedIn adds a wrinkle: Community Management API Development Tier defaults were raised to 500 requests per app and 100 per member, and integrations are expected to be completed within twelve months of receiving access, so a stalled project can lose it. On support, look for a public status page with real incident history.

The vendors, scored

Six vendors, each with the case where it genuinely wins. Details reflect public documentation at time of writing and move often.

Ayrshare. The clearest published pricing ladder and the best-documented webhook contract in the category. The profile model is the right shape if you resell publishing to many tenants who each post modestly, and the wrong shape for a single-brand, very-high-volume agent product. Wins at: multi-tenant resale with real per-customer isolation.

Blotato. Strong on native-API explanation, thin on webhooks in its public writing, which is a real gap given how central callbacks are. Wins at: understanding underlying platform constraints before you buy anything.

bundle.social. The best per-platform documentation of its kind. It defers webhook detail to separate material, so read that too. Wins at: depth of per-platform reference.

Post for Me. Nine platforms, SDKs for JavaScript, TypeScript, Python, Ruby and Go, webhooks for both connections and post status, and the most explicit statement in the category of the quickstart-versus-white-label distinction. Wins at: fastest cheap prototype, and clearest statement of whose app it is.

Upload-Post. A free tier and a large MCP server make it the fastest way to have an agent posting today. The 22-platform count includes long-tail destinations, so read it as reach rather than depth. Wins at: zero-cost evaluation and agent-native testing.

OctoSpark. We are built for humans and agents sharing one publishing surface: dashboard, CLI and MCP over the same API, with approvals, per-client workspaces and analytics. If you want a bare publish endpoint, a per-post vendor is cheaper, and we do not carry long-tail destinations like Lemmy. Our pricing is published; run the question 1 math against it.

Building direct instead: the reality check

The case for building direct is stronger than vendors admit and weaker than engineers assume. App review is not one queue but one per platform. TikTok requires the video.publish scope approved and user-authorized, and until you pass audit everything posts privately with a five-user cap. Meta requires business verification for advanced access. LinkedIn expects completion within twelve months. Each wants a demo video, a privacy policy and a reviewer account that reproduces the flow. Assume review rounds, not a review.

Per-platform product rules are code too. TikTok requires you to display the creator's nickname, force a manual privacy selection with no default, show a content preview, display a Music Usage Confirmation, and never add promotional watermarks. Those are compliance requirements, and UI work as much as API work.

Then ongoing cost. X uses pay-per-usage pricing: $0.015 per standard post created and $0.200 per post containing a URL. At 5,000 link posts per month that is $1,000 on X alone, which reframes every "the vendor is expensive" conversation.

Build direct for one or two platforms, or when the integration is your differentiator. Buy at five or more platforms, under about five engineers, or when publishing is a feature rather than the product.

Your one-afternoon checklist

Open each vendor's docs in a tab. Stop early if any of the first four is a hard no.

1. Compute monthly cost at your real account count and post volume under each shape, then again at 3x volume. Note where the crossover sits.
2. Pick your two most important platforms, list every format you publish, and find each by name in the docs. Ask about anything missing, in writing.
3. Search for "webhook". Confirm an ack window, a retry schedule and a stable event ID. No stable ID is a blocking failure.
4. Search for "sandbox", "test mode" or "dry run". Decide now how CI works if the answer is nothing.
5. Determine whose developer app holds tokens, and whether a white-label path preserves existing connections.
6. Ask directly: if we leave, do our users re-authenticate? Get it in writing.
7. Check refresh-failure notification, rate-limit surfacing and retry idempotency.
8. Open the status page and read six months of incidents.
9. Build the smallest thing: authenticate one account, publish one image and one video post, handle one webhook. A vendor that survives that in under two hours has true docs.

The rubric is deliberately vendor-neutral because the answers move faster than any comparison page can track. Run it yourself, write your scores down, and re-run it before your next renewal. If you want to score us against it, start a free account and work through step 9 first.