Launched this week
Buffer API
One API to publish across every social platform.
243 followers
One API to publish across every social platform.
243 followers
Buffer's API lets you publish and manage content across 11 social platforms through a single endpoint. Connect it to AI assistants, no-code automation tools, or build full custom integrations. Ships with an MCP server, pre-built automation templates, a CLI, and an interactive API explorer. Available on every Buffer plan, including Free.
Buffer
I’ve built a TRMNL plugin with the Buffer API; it shows my queue counts, along with my next scheduled posts and previously sent posts, on an e-ink display sitting on my desk. I’ll make this available for installation soon.
The API is straightforward to work with, and AI tooling makes prototyping extremely quick. If you're building anything that touches social media, this is worth a look.
RiteKit Company Logo API
The one API for every platform pitch is the thing every social tool maker has wished into existence for ten years. The fact you're shipping it as a public product instead of keeping it for the Buffer app alone is the bigger deal here.
Webhook question (probably my most selfish question of the day): is there a sent-post event fired when a scheduled post actually publishes, with the resulting permalink in the payload? I'm building tooling that monitors reply threads on outbound posts, and the gap between "scheduled in CMS" and "live with a URL" has historically been the worst part of stitching that loop together. If yes, you've eliminated a whole class of polling jobs that nobody enjoys writing.
Smaller question: how are you handling X's per-account rate caps when an org has multiple Buffer-connected X accounts? Limit enforced per-account, or pooled across the org? Asking because someone is definitely going to try to send 300 posts at 9am Monday on launch day and find out the hard way.
Congrats on shipping. This is the API I've been complaining about how it hasn''t been updated in what... 15 years...?
Buffer
👋 Hey everyone, Mike here, another one of the makers on the Buffer team.
A bit more about the API:
Buffer's API lets you connect Buffer to the tools you already use, whether that's an AI agent, a no-code automation tool, or your own stack. You can publish, schedule, and manage your social presence from wherever you already work.
Under the hood: GraphQL API, MCP server, CLI, managed OAuth, pre-built workflow templates with no-code tools like Zapier and n8n, and an interactive API explorer.
A few more examples of what people have been building with it:
An automated weekly reporting system across 77 social channels in 10 languages, built with n8n by someone who isn't a developer.
A Friday morning Slack bot that recaps what was posted, what's scheduled, and what's missing. Plus a full LinkedIn content library and analyzer on Lovable, both built entirely through conversation with AI.
A power-user layer on top of Buffer with thread splitting, a content calendar with planning notes, and a snippet library.
A Substack growth platform for creators, with Buffer handling social distribution automatically.
It's also available on every Buffer plan, including Free.
Let us know if you have any questions and excited to see what other folks build with it!
Super interesting idea. How would the pricing work for independent software vendors? I am thinking about adding scheduled social media posts on top of our current product.
Buffer
@myuan Thanks! Standard pricing is at buffer.com/pricing but if you're building something where those limits don't cut it (which is likely if you're scheduling for a bunch of your own users), get in touch and we'll work out the right tier! Docs at developers.buffer.com if you want to poke around first.
And if additional parameters need to be specified during publishing (for example, privacy settings), can those also be managed?
Buffer
@natalia_iankovych Hi! Each platform has its own metadata input on the createPost mutation. Reference here: developers.buffer.com/types/PostInputMetaData.html. The exact fields available vary by network (LinkedIn has first comments, Pinterest has boards, etc.).
Most social publishing APIs fall apart on edge cases like platform-specific media constraints, rate limit variance across accounts, or diff post formats per network. Curious how the Buffer API handles those inconsistencies at the normalization layer. Do you expose a unified schema and translate per-platform, or does the caller still need to know what Twitter vs LinkedIn expects?
Buffer
Hey there@fberrez1!
We expose a single GraphQL API with a unified data model (posts, channels, organizations), so you integrate once instead of juggling separate APIs for each social network. You use the same mutations to create, schedule, and manage posts across Instagram, LinkedIn, X, TikTok, YouTube etc., and we handle auth, routing, and most of the cross‑platform reconciliation behind the scenes.
At the same time, not all networks are identical. Every post is tied to a specific channel type, and we validate it against that platform’s rules, returning clear, structured errors when you hit things like media constraints, text limits, or unsupported combinations. Rate limiting is handled at the Buffer layer, so your integration talks to one rate‑limit model even though we’re managing multiple downstream APIs.
For tailoring content, we also use a metadata layer: each post has a shared core shape (text, media, scheduled time, etc.), plus an optional metadata object that fans out into per‑platform fields (for example, Instagram post vs. reel options, LinkedIn‑specific link settings, YouTube‑style settings). That means you can send a simple “works everywhere” payload when you want speed, and then selectively add metadata when you want to optimize per network (all through the same mutation and schema).
So tl;dr: you get a unified schema and consistent mental model, plus per‑platform metadata and validation that informs you about what each social network will actually accept :)
One API for every platform is the right framing — the rate-limit and format normalization is where everyone burns weeks. Question: how are you handling platforms that change their content rules without notice (Twitter character limits, LinkedIn media specs)? Have to deal with the same kind of cross-platform output problem with StoryRoute, my interactive travel app where city-exploration stories need to render cleanly on mobile web and inside socials — the format-drift problem never really goes away.
Buffer
@samir_asadov Hey Samir! Our external API is built on top of the same schema as our internal one. Any changes that happen within our product, including any limitations from our third party partners, would then be reflected automatically in our API.