// HOW-TO · AUTOMATION

How to build a social content engine with the Buffer API (2026)

Wire AI content generation into Buffer's GraphQL API: get a key, query channels, draft posts per platform, host media, and schedule across 11 networks.

Last verified · 2026-10-23 · by Moe Ameen

Published 2026-06-22 · Updated 2026-10-23

Short answer

To build a social content engine on the Buffer API, create a personal API key under Settings, then API, and call the GraphQL endpoint at api.buffer.com. Query your channels for their IDs, generate posts per platform with your own model, host every image and video at a stable URL, and send each post through the createPost mutation with addToQueue or a customScheduled dueAt time. Pace calls within Buffer's rate limits.

Key takeaways

Buffer's API is one GraphQL endpoint at api.buffer.com with Bearer-token auth.
createPost needs channel IDs, so query your channels first.
Post assets take a URL, so re-host model output at a stable address before you post.
Since May 12, 2026, assets is an array of AssetInput, not the old AssetsInput object.
Every plan gets 100 requests per 15 minutes; Team gets 500 per day.

Buffer has a public API, and it changes what a solo builder can wire up over a weekend. It is a single GraphQL endpoint at https://api.buffer.com that creates, schedules, and deletes posts through one createPost mutation. Buffer's posts guide lists Instagram, Threads, LinkedIn, X, Facebook, Google Business Profiles, Mastodon, YouTube, Pinterest, and Bluesky. You do not learn a separate API or OAuth flow per platform; you call one mutation with a channel ID and Buffer handles the publish.

That makes Buffer a clean publishing-and-scheduling backbone. What it is not is a content engine on its own: the API publishes what you hand it, but it does not write the copy, design the image, or cut the video — and its post assets take a URL to the file, so every image and video has to live at a reachable URL before you reference it. A real engine is the AI generation layer you build in front of Buffer plus the durable media hosting underneath it.

This guide wires that engine end to end: authenticate, discover your channels, generate per-platform posts with a model, host the media durably, and schedule the batch through Buffer. It is specific about the parts that bite — the May 2026 assets-input change and the expiring-media-URL trap that ships blank posts.

How do you build a content engine on the Buffer API, step by step?

Generate a Buffer API key and confirm the endpoint. In your Buffer account go to Settings → API and create a personal API key. Every request goes to https://api.buffer.com as a POST with an Authorization: Bearer YOUR_TOKEN header and a GraphQL body — no SDK is required; Postman, curl, or any GraphQL client works. Store the key as an environment variable, never in source. Personal keys reach all organizations you belong to but act as your account only; if you are building an app other people authorize, register it for OAuth 2.0 (Authorization Code flow with PKCE) at the same Settings → API screen instead.
Query your channels to get their IDs. createPost targets a channel by ID, not by name, so your first real call lists them. Query the channels query (see Buffer's Get Channels / Get Filtered Channels examples) to pull every connected channel with its id, service (instagram, linkedin, etc.), and name. Cache that map in your engine — channel IDs are the routing table for everything downstream. Connect the social accounts inside Buffer's UI first; the API publishes to channels Buffer is already authorized for, it does not add new account connections.
Build the generation layer in front of Buffer. Buffer publishes; it does not generate. This is the half you own. Take your source — a podcast, a long video, a blog, a list of prompts — and run a model to draft the posts: an LLM (Claude- or GPT-class) for captions, threads, and text; an image model for graphics; an avatar/video tool for shorts. Generate per platform, not one caption for every network, and check each network's current character limit before you set your output length. Output a structured object per post — channelId, text, optional media URL, scheduled time — that maps straight onto the createPost input.
Host every image and video at a public URL first. The assets field on a Buffer post takes a URL to the file (ImageAssetInput and VideoAssetInput each have a required url field), so the media has to already live somewhere Buffer can reach. So before you call createPost for any image or video post, upload the bytes to your own storage (S3, R2, Cloudflare, Supabase Storage) and get a stable public URL. Do not pass the raw URL your image or video model returned: those expire, and Buffer fetching a dead URL is how a post ships text-only or fails outright.
Create and schedule posts with the createPost mutation. A single createPost mutation serves every supported network. The core inputs are text, channelId, and schedulingType (automatic). For timing you choose a mode: addToQueue drops the post into the next open slot from that channel's posting schedule, while customScheduled publishes at an exact moment you pass as dueAt in ISO 8601 UTC (e.g. 2026-03-10T15:00:00.000Z). For an engine, loop your generated batch and fire one mutation per post; stagger the dueAt values so the whole batch does not land at once.
Use the current assets input shape (post–May 2026). On 12 May 2026 Buffer changed how media is submitted: CreatePostInput.assets (and EditPostInput / ThreadedPostInput) moved from the old AssetsInput object to an array, [AssetInput!]!. Buffer removed the legacy AssetsInput type in the same change. If you are copying an older snippet or an LLM-generated example trained on the old schema, pass assets as a list of asset objects, not a single object. Threads on X, Bluesky, Threads, and Mastodon are built through channel-specific metadata in the same createPost input.
Respect rate limits and make every call idempotent. All Buffer plans include API access, but the limits scale with tier: 100 requests per 15 minutes on every plan; per 24 hours 250 (Free and Essentials) or 500 (Team); per 30 days 3,000 (Free), 7,500 (Essentials), or 15,000 (Team). For a high-volume engine, batch and pace your createPost calls and back off on a 429. Tag each job with a unique key on your side and check it before firing, so a retry after a network blip never double-creates the same post. Partners needing higher limits email developersupport@buffer.com.
Add a review gate, or wire the MCP server for agent control. Do not run source-to-published with no human in the loop on day one. Land drafts in a review state in your own app, approve or edit, and only call createPost on approved items — feed every edit back into your generation prompt. If your interface is an AI assistant rather than a dashboard, Buffer's API reference lists MCP client connections as a connected-app category, so an agent can draft and queue posts through the same API. Keep a kill switch either way.

What breaks a Buffer API integration?

Assets are URLs. Every image and video must be hosted at a reachable URL before you reference it in the assets field.
Passing an expiring provider URL as the asset. Many image and video model URLs expire; if Buffer fetches a dead URL at publish time the post ships text-only or fails. Re-host to durable storage and pass that URL.
Using the legacy assets format. After 12 May 2026, CreatePostInput.assets is an array [AssetInput!]!, not the old AssetsInput object — old snippets and stale LLM examples silently break. Use the array shape.
Targeting a channel by name. createPost needs the channel ID, not the handle. Query channels first and build an ID map; channels must already be connected inside Buffer.
Ignoring per-plan rate limits. The 15-minute cap is 100 on every tier; a tight loop firing dozens of posts will hit it. Pace the batch and back off on 429.
Expecting Buffer to generate content. The API publishes and schedules only — it writes nothing. Brand voice, copy, images, and video are entirely your generation layer's job.
Writing one caption for every network. The same string can blow past X's limit or read flat on LinkedIn. Generate per platform and respect each ceiling.

Where does Kompozy fit next to the Buffer API?

The Buffer API gives you the cleanest possible publishing half of an engine — one mutation, many networks, real scheduling. Steps 3 and 4 above are the half it leaves to you: generate the actual posts, and host the media durably so Buffer can fetch it. That is precisely the surface Kompozy fills.

Kompozy generates the content the Buffer API will not: 20 formats spanning persona/avatar shorts, VFX hooks, clipped verticals, carousels, quote graphics, face-locked persona images, blogs, and newsletters — governed by a Persona Brief so 40 posts a week read as one voice.

And it persists every generated image and video to durable storage at creation time, which is the exact fix for the expiring-URL trap that breaks Buffer's asset fetch: the URL you would hand Buffer is permanent, not a dead provider link.

Two honest ways to use them together. If you have standardized on Buffer's queue, use Kompozy as the generation-plus-durable-hosting layer and feed its permanent media URLs into your createPost calls. Or skip the glue entirely: Kompozy already publishes natively to 9 platforms with per-platform limits, retries, and a review gate handled, so you do not maintain the channel-ID map, the rate-limit backoff, or the assets-input migration yourself. Starter tier ($199/mo for 5,500 credits, 4 platforms) runs a solo single-source engine; Pro ($499/mo for 18,000 credits, 9 platforms and full autopilot) covers multi-source, higher-volume operations; Enterprise is available through Contact Sales. Buffer wins if its queue and analytics are already your hub; Kompozy wins if you would rather not own the generation and media plumbing at all.

What does this look like in Kompozy?

A real persona tweet graphic from the Kompozy workspace, the kind of generated post an engine like this would send to Buffer. It's a format example, not a post published through Buffer.

Persona tweet graphic generated in Kompozy — Real output · Kompozy Persona tweet format · from the Kompozy workspace

Who is this for, and who should skip it?

Best for:

Developers who already use Buffer and want to add an AI generation layer.
Solo builders who would rather call one mutation than maintain a separate API per network.
Teams that want a human to approve drafts before createPost runs.

Not ideal for:

Anyone who wants content written for them. The API only publishes what you send.
High-volume senders who would blow past the 30-day request caps.
Platform features Buffer doesn't expose. Go direct for those.

Frequently asked questions

Does Buffer have a public API in 2026?

Yes. Buffer has a public GraphQL API at https://api.buffer.com. It creates, schedules, and deletes posts, creates ideas, and queries your account, organizations, and channels. You authenticate with a personal API key (Bearer token) or OAuth 2.0.

Can I publish images and videos through the Buffer API?

Yes. You host the image or video yourself, then reference its URL in the post's assets field. As of 12 May 2026 the assets input is an array ([AssetInput!]!), so make sure you are not using the older object format.

Does the Buffer API generate content for me?

No. The API is a publishing and scheduling backbone — it publishes exactly what you hand it. Generating the copy, images, and video, and keeping them on-brand, is a separate layer you build (or buy) in front of Buffer. That generation layer is what makes it a content engine rather than a scheduler.

How do I schedule a post for a specific time?

In createPost, set schedulingType to automatic and use mode customScheduled with dueAt as an ISO 8601 UTC timestamp like 2026-03-10T15:00:00.000Z. To instead drop the post into the channel's next open slot, use mode addToQueue and skip the explicit time.

What are the Buffer API rate limits?

All plans include API access. The 15-minute limit is 100 requests on every plan; the 24-hour limit is 250 on Free and Essentials and 500 on Team; the 30-day limit is 3,000 (Free), 7,500 (Essentials), or 15,000 (Team). Higher limits are available to partners by request via developersupport@buffer.com.

Buffer API or build my own per-platform integrations?

Buffer's one createPost mutation across its supported networks saves you from maintaining a separate API, OAuth flow, and rate-limit regime per platform, which is a lot of plumbing. The trade-off is you live inside Buffer's queue model and its media constraints. For most builders the single-mutation simplicity wins; build direct only if you need platform features Buffer does not expose.

How do we know this?

We checked every endpoint, limit and schema detail on this page against Buffer's developer docs against the sources listed below on 2026-10-23, and rewrote or removed any figure we couldn't confirm there. Kompozy plan details come from kompozy.io/pricing.

Sources

Buffer API — Authentication (read 2026-10-23)
Buffer API — Getting started (read 2026-10-23)
Buffer API — Posts and scheduling (read 2026-10-23)
Buffer API — Rate limits (read 2026-10-23)
Buffer API — Changelog (read 2026-10-23)
Buffer API — Reference (read 2026-10-23)
Kompozy — Pricing (read 2026-10-23)