Picking a social media API used to mean asking which schedulers had one. All eight compared below now do, and all eight ship an MCP server as well. The question that decides your build is what the API is allowed to do, and the ceilings that stop you belong to Meta, TikTok, LinkedIn and X.
Key takeaways
- Six of the seven networks cannot schedule. The queue is the product.
- Meta publishes two Instagram daily limits on one page, 50 and 100.
- X charges per post, and 13 times more when the post carries a link.
- Five of eight vendors publish a rate limit, using seven different windows.
- Three of the eight have a free tier you can build against today.
What does a social media API actually do?
It holds your post. That sounds trivial until you check the platform APIs underneath, because six of the seven networks Zilfu publishes to accept no future timestamp at all. Tools with longer lists inherit the same problem on more networks, not fewer. You either publish now or you do not publish.
We checked each one against its own specification or reference rather than its marketing page. X's OpenAPI document has 16 properties on post creation and none of them schedules; all six occurrences of "scheduled" in the whole spec describe Spaces. Pinterest's v5 specification, version 5.28.0, has 189 paths and exactly one containing "schedules", which belongs to /ad_accounts/{ad_account_id}/schedules. The TikTok Content Posting API and the LinkedIn Posts API contain the string "schedul" zero times each.
Instagram is the one that surprises people, because it feels like it should. Its publishing reference lists no scheduling parameter anywhere: you POST a media container, then POST again to publish it, and the second call is what puts the post live. Threads is the same shape, and Meta says so obliquely by telling developers to "enforce the publishing rate limit, especially if your app allows app users to schedule posts to be published in the future" (Meta). Your app. Not theirs.
Facebook Pages is the exception, and it is a real one. Its feed endpoint takes scheduled_publish_time, described as a "UNIX timestamp indicating when post should go live. Must be date between 10 minutes and 75 days from the time of the API request" (Meta). One endpoint, out of seven networks.
So when you buy a social media scheduling API, the timestamp handling, the retry after a failure, the token refresh and the per-network payload translation are the things you are actually buying. The publish call itself is the easy part.
Worth knowing: Zilfu sells one of the tools compared here, so read this as an argument rather than a verdict. What we can do instead of asking for trust is quote each vendor's own documentation and show where the numbers came from, which is what the rest of this page does.
Which of these are you?
The eight products below split into two shapes, and picking the wrong shape costs more than picking the wrong vendor within it.
You are embedding social posting inside your own product, for tens or thousands of end users who each connect their own accounts. You need breadth of networks, a quota counted in something that scales with customers, and no interface at all. Ayrshare, bundle.social, Post For Me and Zernio are built for this, and they bill per profile, per post or per account accordingly.
You are a team that publishes its own content and wants to automate part of it. You need a calendar a human can open, an approval step, and an API that reaches the same queue the humans use. Zilfu, Buffer, Postiz and Metricool are this shape. The API is a surface on a product, not the product.
The second group is easy to underrate if you are technical, because the interface looks like overhead. It stops looking like overhead the first time a scheduled post fails at 3am, or a client asks to see next week before it goes out, or an assistant drafts something nobody approved. Everything below applies to both shapes; the quota table is where they diverge.
Which limit actually stops you?
Three ceilings sit between your script and a published post, and they are enforced by three different parties.
- The platform. Meta caps published posts per account per day, X charges per call, and TikTok and LinkedIn gate access rather than volume. No scheduler can lift any of them.
- The scheduler's own throttle. Requests per second, minute, hour or 30-day window, depending on the vendor.
- The scheduler's commercial quota. Posts a month, connected accounts, channels, brands or social profiles, depending on how the bill is counted.
For a single Instagram account the platform's number is the lowest of the three, and it is the one the pricing pages leave out. We read five of them and none names a platform cap. Zernio's carries a row reading "Unlimited posts, threads, first comment, queue, calendar", with the word "Unlimited" filling all fourteen cells beside it.
Converted into the same unit, posts a day on one account: Zilfu's publish limiter allows 30 a minute, so 43,200. Buffer's published 24-hour limit on Free is 250 calls, and a 3,000-call quota per 30 days sits behind it, so 100 a day sustained. Meta allows 50.
How much headroom that leaves you differs by a factor of 170 between two vendors. Above Meta's 50, Zilfu's throttle is roughly three orders of magnitude clear; Buffer's free plan is a factor of five on the day and a factor of two once its 30-day quota is averaged out. On Buffer Free both ceilings are effectively in play at once. On a paid plan almost anywhere, only Meta's is. None of that appears on a pricing page, because "unlimited posts" means unlimited by that vendor's counter. The network's counter is still running, and it is the smaller one.
One vendor builds this into the product. bundle.social exposes GET /api/v1/organization/usage/daily-limits, which returns used, limit and remaining for one connected account on a given UTC day. Its docs describe the quota as keyed to "the platform account itself (platform + account id), not by the connection or the team", so the same account added to five teams still shares one quota. Of the rate-limit pages we could read, bundle.social's is the only one documenting an endpoint for the platform's remaining quota. Several vendors report their own: Buffer returns RateLimit headers on every response and shows live usage in a dashboard. That is a different number, and it is not the one that stops you.
Is there a free social media API?
Three, with different shapes of catch.
- Buffer. Full GraphQL API and MCP server on the free plan. The ceiling is 3,000 requests per 30 days and one API key. No webhooks at any tier.
- bundle.social. Free tier at 20 posts and 50 comments a month per organisation, on the same three-layer throttle as its paid plans. Its per-platform daily caps start low: 5 a day on X, TikTok and Snapchat, 10 on every other network it supports.
- Zilfu. REST API, webhooks and the MCP server on every plan including Free, which covers 2 connected accounts and 20 posts a month.
Two costs that used to be someone else's. Ayrshare's entry point is now $149 a month, with a 28-day trial on Launch access only. And X meters every post creation as a credit purchase, which lands on whoever owns the developer app.
What can each social media API publish?
The gates differ enough per network that a "supported platforms" checkmark tells you almost nothing. Here is what each one costs you in practice.
The Instagram posting API: 50 a day, or 100?
Meta's content publishing documentation states both numbers, on the same page, under different headings. Under Rate Limit: "Instagram accounts are limited to 100 API-published posts within a 24-hour moving period. Carousels count as a single post." Under Limitations, in the carousel container section: "Accounts are limited to 50 published posts within a 24-hour period. Publishing a carousel counts as a single post." The carousel clause is identical in both, so it is not the distinction.
Two vendors read the page and repeated different numbers. Ayrshare's help centre tells developers that "Instagram 50 posts every 24 hours", in a passage whose point is that Ayrshare "generally does not impose limits on posting beyond the social networks' requirements". bundle.social went the other way and enforces 100 posts a day on its Business tier, matching Meta's Rate Limit section. Neither is wrong about the page. The page is wrong about itself, and the ambiguity is now downstream in two products.
Two other constraints on this endpoint are easy to miss. Publishing is a two-step flow: you POST /<IG_ID>/media to build a container, then POST /<IG_ID>/media_publish to release it. And "JPEG is the only image format supported", so PNG conversion is your job or your scheduler's. Our Instagram channel page lists which post types survive that round trip.
The TikTok content posting API: audited or invisible
TikTok gates the endpoint twice. You need the video.publish scope approved, and then you need an audit. Its own words: "All content posted by unaudited clients will be restricted to private viewing mode. Once you have successfully tested your integration, to lift the restrictions on content visibility, your API client must undergo an audit to verify compliance with our Terms of Service" (TikTok).
This is the clearest case in the category for buying rather than building. Posting through an established scheduler inherits its audited client, so your posts are public from day one; building your own means the audit is yours to pass first. What a given tool can actually publish there is still narrower than the API allows, as our TikTok channel page sets out.
The X posting API: you now pay per post
X replaced its subscription tiers with pay-per-usage credits, and posting is a billable write. From its own pricing page: Post: Create is $0.015 per request, and Post: Create (with URL) is $0.200 per request (X).
A link in the post multiplies its cost by more than thirteen. One link post a day for a year is $73 in X credits; the same cadence without links is $5.48. Reads are charged too, at $0.005 per post returned, and pay-per-usage accounts are "capped at 2 million Post reads per monthly billing cycle". Webhook events are billed per delivery, with post.create at $0.005.
That reprices a whole category of automation. Polling X for analytics, or fanning a link campaign out across accounts, now carries a marginal cost per call.
It also changes who pays. Ayrshare's documentation states that "Starting March 31, 2026, all X/Twitter operations through Ayrshare require your own OAuth 1.0a credentials" and that requests without them "will be rejected". You create one X developer app per Ayrshare account, then pass two extra headers on every request that targets X.
Ayrshare's home page says an agent using it "does not need to know X BYOK rules". Once the app exists, that is fair. But the headers still ride on every call, and X's credit meter is now attached to your card rather than the vendor's. Zernio documents the same pattern as an option, calling it BYOK for "users who provide their own X API credentials". The others we read say nothing either way, which makes it a question worth asking before you sign rather than an assumption worth making.
The LinkedIn posting API: approved users only
LinkedIn's restrictions are structural rather than numeric, which makes them harder to design around than a daily cap. Reading posts, comments and likes on a member's behalf uses a permission that is "restricted and is available to approved users only". Creation accepts one state: "PUBLISHED is the only accepted field during creation", so an API-created draft is not possible even though DRAFT exists in responses.
The one that catches people mid-build: "The Posts API does not support URL scraping for article post creation, as it introduces unpredictability in how a post will appear when created by API partners. Instead, API partners must set article fields such as thumbnail, title, and description within the post when creating an article post" (LinkedIn). A link posted through the API has no preview unless you build one, upload the thumbnail through the Images API first, and attach it. It is the kind of thing you discover after the first link post publishes bare, and our LinkedIn channel page covers what else differs there.
The Threads API: the most generous ceiling here
Threads publishes clean numbers, and they beat Instagram's on either of Meta's two readings of it. Per profile, in a 24-hour moving period: 250 API-published posts, 1,000 replies, 100 deletions and 500 location searches. bundle.social's Business tier caps Threads at 250 a day, exactly matching Meta.
Meta also states the API's purpose narrowly. You may use it, in Meta's words, "to enable people to create and publish content on a person's behalf on Threads, and to display those posts within your app solely to the person who created it." Showing someone else's Threads posts in your product sits outside that grant.
The Facebook posting API: the only one that schedules for you
The Page feed endpoint accepts scheduled_publish_time, a "UNIX timestamp indicating when post should go live. Must be date between 10 minutes and 75 days from the time of the API request" (Meta). Hand it a timestamp and Facebook holds the post for you, up to two and a half months out.
Zilfu does not use it, and the reason generalises. Holding every network's queue in one place keeps edits, cancellations and approvals consistent, and it means one code path rather than two. It also means a post cancelled in the dashboard is genuinely cancelled, rather than still sitting on Meta's side waiting to fire. Our Facebook channel page covers what publishes and what does not.
The Pinterest API: 189 paths, and the scheduler is an ads endpoint
Pinterest's v5 specification confirms what its help centre implies. POST /pins accepts eleven properties, none of which is a time. Searching the whole 5.28.0 document for publish_at, scheduled_at and publish_date returns zero matches. Any third-party Pinterest scheduler, ours included, has to hold that queue itself.
How do social media APIs compare on quota?
Eight products, five different billing units, and three of them publish no rate limit we could read. Every unmarked cell below is quoted or paraphrased from the vendor's own documentation or pricing page, checked on 1 August 2026.
| Product | The bill counts | The API quota counts | Published rate limit | Webhooks | MCP |
|---|---|---|---|---|---|
| Zilfu | Accounts | Requests per minute | 120/min per token, 30/min publishing | Yes, 8 events | Yes, every plan |
| Buffer | Channels * | Requests per window, tiered | 100/15min, 250 to 500/day, 3,000 to 15,000/30 days | No | Yes, every plan |
| Ayrshare | Social profiles | Not published, defers to networks | No own number * | Yes, from Launch * | Yes |
| bundle.social | Posts per month | Posts per month, plus platform caps | 100/s, 500/10s, 2,000/min | Yes | Yes |
| Postiz | Channels | Requests per hour, not tiered | 90/hour, 100 on cloud | Yes | Yes |
| Post For Me | Successful posts per month | Successful posts per month | Documented, no public figure * | Yes | Yes |
| Zernio | Accounts | Per connected account | 300/15min per account * | Yes | Yes, 280+ tools |
| Metricool | Brands * | Not published * | Not stated * | Undocumented * | Yes, every plan * |
* Marks an answer the vendor does not state outright on the pages we could read. Ayrshare publishes no request-per-window figure of its own, pointing instead at the networks' limits and a fair-use policy; webhooks appear as a Launch-plan inclusion, and only its X real-time webhooks are Enterprise. Zernio publishes a guide titled "API rate limits by plan" and per-endpoint figures, but that page is JavaScript-rendered and its per-plan table did not resolve for us. Post For Me has a public help article on rate limits with no figure on the page itself. Buffer's and Metricool's billing units, and Metricool's MCP tiering, come from their pricing pages rather than the developer docs read here; the Metricool row is the one we sourced least directly, and our Metricool alternatives piece works it properly.
The billing units reduce to five: accounts (Zilfu, Zernio), channels (Buffer, Postiz), posts a month (bundle.social, Post For Me), social profiles (Ayrshare) and brands (Metricool). The rate limits do not reduce at all. The five vendors publishing a figure use seven different windows between them: one second, ten seconds and a minute at bundle.social; a minute at Zilfu; an hour at Postiz; fifteen minutes at Zernio; and fifteen minutes, twenty-four hours and thirty days at Buffer. Comparing two of these products on quota means converting both into the workload you actually run.
Three more observations that a feature grid hides.
The Buffer API: the plan tiers are the rate limits
Buffer's API is on every plan including Free, but Free gets 1 API key, 1 app client and 3,000 requests per 30 days. Essentials gets 3 keys and 7,500. Team gets 5 and 15,000. The 15-minute window is 100 on all three. It also enforces query-level caps: a maximum complexity of 175,000 points, depth 25, 30 aliases, 50 directives and 15,000 tokens per document.
For a category that historically gated the API behind a tier, moving the gate to the meter is the more honest design. It is also invisible on a feature grid, which is where a comparison usually stops. Buffer's remaining gaps, webhooks included, are taken apart in our Buffer alternatives piece.
Postiz: one global limit, and you can self-host it
Postiz decouples the throttle from the plan entirely. Its docs state the limit is "a single global value for the whole instance" that "doesn't tier by subscription plan. Plans tier on channel and post-per-month quotas instead", and self-hosters can change it with an environment variable. Its docs publish a self-hosted base URL alongside the cloud one, which none of the other seven does, though Post For Me lists an open-source page we did not open.
Ayrshare pricing: the unit is the customer, not the account
One Ayrshare profile is one brand or location, connected to any number of networks. That is unusually good value if you are embedding social posting for many end users, and unusually poor if you are one business with several accounts on one network.
There is also no free tier. Billed monthly, Premium is $149 for one profile, Launch $299 for up to ten, and Business $599 for thirty included, with Business dropping to $499 on annual billing. The pricing page states Premium, Business and Enterprise are "billed at signup (no free trial)". The 28-day trial covers Launch access only, so the cheapest way to evaluate it is $149.
Do you still need webhooks, or is MCP enough?
They answer different questions, and the market has quietly decided the AI connector is the cheaper one to give away.
MCP tells an assistant what it can do. Metricool ships its MCP server on every plan including Free while gating its REST API to Advanced; Buffer ships both on every plan; Zilfu ships both plus webhooks on every plan. We take that inversion apart properly in our Buffer alternatives piece, where it holds across three vendors.
Webhooks tell your systems what happened. Without them a failed publish is invisible until something polls, and polling is exactly what X's new read pricing makes expensive. Buffer has none, which is conspicuous next to how complete the rest of its developer surface is. Zilfu fires eight events: post.published, post.failed, post.scheduled, comment.published, comment.failed, comment.received, account.connected and account.disconnected.
If you are wiring an assistant into a workflow rather than a codebase, our social media automation tools roundup covers the no-code lanes, and the agents page covers the MCP setup.
Can an agent post without a human seeing it first?
That is the question an MCP server quietly creates, and almost nothing in this category answers it. Once an assistant holds a token that can publish, every one of these APIs will let it publish. The scheduler is the only place a check can live, because the networks have no concept of a pending post: as established above, six of the seven publish immediately or not at all.
Zilfu's answer is that a post created through the API or MCP can land in a pending state that a human approves before anything goes out. The agent drafts, a person releases it, and the same approval loop serves the humans on the calendar. Nothing in the token has to be trusted with the last step.
That matters more as the drafting gets automated. An assistant that writes ten posts a week is useful; an assistant that publishes ten posts a week to a client's account with nobody reading them is a liability, and no rate limit protects you from it. If you are pointing an agent at a production account, ask each vendor where the human check sits before you compare quotas.
Five questions to ask before you pick one
Ranking these products against each other is close to meaningless, because the constraint that stops you is usually not the one the vendor is competing on. Ask these instead.
- Which shape are you? Embedding posting for your own end users, or automating a team's own publishing. That answer rules half this list in or out before any feature comparison starts.
- Which networks do you need, and what does each one gate? TikTok needs an audit, LinkedIn needs approval, X needs credits. Buying an audited client is a legitimate reason to pick a vendor.
- What is the quota counted in? Requests, posts, profiles, accounts or channels. Two products can be identical on features and differ tenfold on the workload you actually run.
- Does the vendor publish that number at all? Three of the eight here do not, and "unlimited" on a pricing page means unlimited by their counter, not the network's.
- Where does a human check the agent? If an assistant will hold a publishing token, find out whether anything can hold its output for review, or whether every call it makes goes straight to a live account.
Where Zilfu fits, and where it does not
If you recognised yourself in the second shape above, this is the part that applies to you. Zilfu is a team scheduling app with a developer surface rather than an API-first product, and that is the whole point of it: the API reaches the same queue, calendar and approval loop the humans use, so an agent and a person are working on one thing rather than two.
The REST API, webhooks and hosted MCP server are on every plan including Free, and one bearer token opens all three. That is 39 paths and 56 operations in the OpenAPI document, plus 15 MCP tools, covering spaces, accounts, slots, posts, media and analytics. Rate limits are 120 requests a minute per token, and 30 a minute per user for anything that creates or reshapes a post. Plans run 2 accounts free, 10 on Pro at $19 a month, 100 on Business at $79 and 300 on Scale at $179. Several accounts on one network cost the same as any other slot, which is where per-profile and per-brand billing gets expensive.
Two smaller things worth knowing. Multi-post X threads are assembled by chaining child posts through the API or MCP, not in the dashboard composer. And if you are working in TypeScript, @zilfu/sdk is generated from the same OpenAPI document the reference is built from, and regenerated in CI whenever the spec changes, so a current SDK matches the current endpoints.
Where it does not fit is worth saying plainly. It publishes to seven networks: Instagram, Threads, Facebook, TikTok, Pinterest, X and LinkedIn. Ayrshare reaches thirteen and bundle.social fifteen, including YouTube, Bluesky, Reddit and Google Business Profile. If you are embedding social posting inside your own product for thousands of end users, an API-first vendor billing per profile is the better architecture and probably the cheaper one. Zilfu has no built-in AI writer and no white-label reporting, its approvals are single-reviewer, and its comment inbox covers Threads, Instagram and Facebook only.
The free plan is 2 accounts and 20 posts a month with the REST API, webhooks and MCP all included, no card and no time limit, so you can run a real integration end to end and see the approval loop work before anyone pays for anything. That is the cheapest way to find out which of the two shapes you actually are, which is the only question on this page that matters.
Sources
All pages fetched 1 August 2026 and searched as raw HTML rather than summarised. Platform specifications were parsed programmatically: X's OpenAPI document and Pinterest's v5 specification were searched by field name, and the TikTok, LinkedIn and Meta pages by string match against the delivered markup.
- Meta. Instagram content publishing.
- Meta. Page feed reference,
scheduled_publish_time. - Meta. Threads API overview and rate limits.
- TikTok. Content Posting API, get started.
- LinkedIn. Posts API.
- X. Pay-per-usage pricing and credits.
- X. OpenAPI specification, post creation schema.
- Pinterest. v5 API description, version 5.28.0.
- Buffer. Rate limits and query limits.
- Buffer. Documentation index and MCP integration.
- Ayrshare. Home page, pricing and API overview.
- Ayrshare. How many posts and API calls can I make?
- bundle.social. Rate limits and pricing.
- Postiz. Public API introduction and pricing.
- Post For Me. Pricing.
- Zernio. Social media API, pricing and developer docs.
- Metricool. MCP limits and plan requirements.