Everything an AI agent can do with the Buffer API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints18
API versionv1
Last updated23 June 2026
Orientation

How the Buffer API works.

The Buffer API is how an app or AI agent works with a Buffer account: listing connected social profiles, queuing and editing posts, sharing a queued post immediately, and reordering or deleting items in the queue. Access is granted through a single OAuth 2.0 access token that carries the whole account's access, because the classic API has no granular per-endpoint permissions to narrow what a call can touch. It does not push events, so an agent learns about queue and posting activity by reading the pending and sent updates rather than receiving a callback.

18Endpoints
6Capability groups
10Read
8Write
0Permissions
Authentication
The classic Buffer API authenticates with a single OAuth 2.0 access token, obtained through the authorization-code flow and sent on each call in the Authorization header or as an access_token parameter. The token represents the whole account's access, not a narrowed subset.
Permissions
Buffer's classic API has no granular per-endpoint scopes. One access token grants account-level access across every method, so an agent holding the token can read every connected profile and queue, edit, share, or delete updates on any of them. There is no built-in way to limit a token to read-only or to a single profile, which is why an external control layer is needed to scope an agent.
Versioning
The classic API is a single, unversioned interface served under a /1 path prefix, with no dated version string to pin. It is in maintenance and restricts new app registrations, and Buffer has built a separate modern API platform, including a GraphQL API and a hosted MCP server, that new integrations are directed to.
Data model
The classic API is organized around profiles and updates: a profile is one connected social account, and an update is a post queued against one or more profiles. Profiles carry posting schedules; updates move through a pending queue and then a sent history, and can be created, edited, shared immediately, deleted, moved to the top, reordered, or shuffled. The API returns JSON over HTTPS and does not push events.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Buffer determines what it can reach. The classic API uses a single OAuth 2.0 access token that carries the account's own access, and Buffer's modern platform adds a hosted server that exposes Buffer to agents.

Ways to connect

Classic REST API

The classic REST API answers at https://api.bufferapp.com under a /1 path prefix and returns JSON. A call authenticates with an OAuth 2.0 access token, sent in the Authorization header or as an access_token parameter. It is in maintenance, and new app registrations against it are restricted.

Best forConnecting an app or AI agent to a Buffer account's queue.
Governed byThe OAuth 2.0 access token and the account access it carries.
Docs ↗

MCP server (Model Context Protocol)

Buffer hosts an official Model Context Protocol server at https://mcp.buffer.com/mcp, part of its modern API platform rather than the classic REST API. An MCP-compatible AI client connects with the endpoint URL and an API key sent in the Authorization header, to query posts, schedules, and engagement and to create posts.

Best forConnecting an MCP-compatible AI agent to Buffer.
Governed byThe API key and the account access it carries.
Docs ↗

Modern GraphQL API

Buffer's modern platform exposes a GraphQL API documented at developers.buffer.com, which supersedes the classic REST API for new builds. It covers accounts, organizations, channels, posts, and ideas, and is the route Buffer directs new integrations to.

Best forNew integrations that the classic API no longer accepts.
Governed byAn API key and the account access it carries.
Docs ↗
Authentication

OAuth 2.0 access token

The classic API uses the OAuth 2.0 authorization-code flow: an app sends the user to bufferapp.com/oauth2/authorize, then exchanges the returned code for an access token at the token endpoint. The token is sent on each call in the Authorization header or as an access_token parameter, and carries the account's own access with no per-endpoint scopes.

TokenOAuth 2.0 access token
Best forServer-side access to a Buffer account
Docs ↗

API key (modern platform)

Buffer's modern platform, including its hosted MCP server, authenticates with an API key sent in the Authorization header. This is separate from the classic API's OAuth token.

TokenAPI key
Best forModern platform and MCP access
Docs ↗
Endpoint reference

Every Buffer API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

User

Read the account behind the access token.1

The classic API has no per-endpoint scopes; the access token carries the account's own access.

Acts onuser
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Profiles

List the connected social media profiles and read a single profile's details.2

Each profile is one connected social account (the service, avatar, timezone, and schedule). No per-endpoint scope.

Acts onprofile
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns 403 with code 1011 if the token has no access to the profile. No per-endpoint scope.

Acts onprofile
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Schedules

Read a profile's posting schedule and set the days and times it posts.2

A schedule is the set of days and times the profile posts at. No per-endpoint scope.

Acts onschedule
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Changes when queued updates go out. Returns code 1013 if a profile's schedule limit is reached. No per-endpoint scope.

Acts onschedule
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Updates

List pending and sent updates, read a single update and its interactions, create and edit updates, share immediately, delete, move to top, reorder, and shuffle the queue.11

Paged through page and count parameters, where count is 1 to 100. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Paged through page and count parameters, where count is 1 to 100. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns code 1020 if the update is not found, 1021 if the token has no access. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; interaction data depends on what the underlying social network exposes. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Takes profile_ids and the text or media. Returns code 1023 or 1028 when a profile's update limit is reached, 1025 for duplicate content. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Edits the text, media, or scheduled time of a queued update. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Publishes now rather than at the scheduled time. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Irreversible; removes the update from the queue. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Returns code 1027 when the update is custom-scheduled rather than in the buffer. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Takes an ordered list of update ids for the profile's queue. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Reshuffles the pending queue for the profile. No per-endpoint scope.

Acts onupdate
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
Read how many times a link has been shared through Buffer.1

Takes a url query parameter and returns its Buffer share count. No per-endpoint scope.

Acts onlink
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Info

Read Buffer's current configuration, including supported services and their limits.1

Read-only metadata about supported services and their limits. No per-endpoint scope.

Acts onconfiguration
Permission (capability)None required
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

The classic Buffer API does not push events. An app or AI agent learns about queue and posting activity by calling the API, such as listing the pending and sent updates for a profile, rather than receiving a callback.

EventWhat it signalsTriggered by
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Buffer limits how fast an app or AI agent can call the classic API through a per-token request rate, and separately caps how many updates a single profile can hold in its queue.

Request rate

Buffer's classic API is rate limited per access token, with the documented limit being 60 authenticated requests per token per minute; exceeding it returns HTTP 429 Too Many Requests. Buffer no longer publishes the classic rate-limit page, so the exact header names and any newer thresholds are not verifiable from a current first-party source. Buffer's modern platform applies its own per-client limits over rolling windows and reports them in RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset response headers.

Pagination

List endpoints for pending and sent updates page through the page and count query parameters, where count sets the page size between 1 and 100. There is no cursor model in the classic API.

Request size

Per-profile limits cap how many updates a queue can hold and how long the text of an update can be; the exact values vary by social service and are returned by the info/configuration endpoint rather than fixed across the API. Creating beyond a profile's update limit returns code 1023 or 1028.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
4031001An access token is required, or the token is missing or invalid.Send a valid OAuth 2.0 access token in the Authorization header or as an access_token parameter.
4031011No authorization to access the requested profile.Confirm the token's account has the profile connected and accessible.
4001004A required parameter is missing from the request.Read the error message, add the missing parameter, and resend.
4001023The update limit for the profile has been reached, so no more updates can be queued.Wait for queued updates to send, or remove some, before creating more.
4001025The update was recently posted, so duplicate content cannot be posted again.Change the content, or target a different profile, before resending.
4001027An update must be in the buffer and not custom-scheduled in order to move it to the top.Confirm the update is a queued buffer item before calling move_to_top.
4041020The requested update could not be found.Confirm the update id is correct and belongs to a profile the token can reach.
Versioning & freshness

Version history.

The classic Buffer API is a single, unversioned interface served under a /1 path prefix, with no dated version string to pin. Buffer has since built a separate modern API platform that supersedes it.

Version history

What changed, and when

Latest versionv1
v1Current version
Classic REST API (single, unversioned)

The classic Buffer API is served under a /1 path prefix at api.bufferapp.com and has no dated version string. It exposes user, profiles, schedules, updates, links, and info methods, authenticated by a single OAuth 2.0 access token. It is in maintenance, restricts new app registrations, and its public reference pages now redirect to Buffer's modern developer platform.

What changed
  • Profiles and updates: list, read, create, edit, share, delete, move to top, reorder, and shuffle.
  • Schedules: read and set a profile's posting times.
  • Links and info: read a link's share count and Buffer's service configuration.
  • No webhooks; activity is learned by polling the pending and sent update lists.
Modern platform
Buffer modern API platform (supersedes the classic API)

Buffer built a separate modern API platform, documented at developers.buffer.com, that supersedes the classic REST API for new builds. It adds a GraphQL API covering accounts, organizations, channels, posts, and ideas, plus an official hosted MCP server, and is where Buffer directs new integrations.

What changed
  • GraphQL API for accounts, organizations, channels, posts, and ideas.
  • Official hosted MCP server at mcp.buffer.com for AI clients.
  • Per-client rate limits reported in RateLimit response headers.
  • Classic REST API reference pages now redirect here.

The classic API is in maintenance and new app registrations against it are restricted; new builds use Buffer's modern platform.

Buffer developer docs ↗
Questions

Buffer API, answered.

How does an agent authenticate with the Buffer API?+
The classic API uses an OAuth 2.0 access token. An app sends the user to bufferapp.com/oauth2/authorize, exchanges the returned code for an access token, and then sends that token on every call in the Authorization header or as an access_token parameter. The token carries the account's own access.
Can a Buffer token be limited to read-only or to one profile?+
Not through Buffer's classic API. It has no granular per-endpoint scopes, so a single access token grants account-level access across every method and every connected profile. Limiting an agent to read-only or to a single profile has to be enforced outside Buffer, by a layer that sits in front of the token and checks each call.
Does Buffer send webhooks?+
The classic API does not push events. An app or AI agent finds out about queue and posting activity by calling the API, such as listing the pending and sent updates for a profile, rather than receiving a callback when something is published.
What are the rate limits?+
The classic API is rate limited per access token, with the documented figure being 60 authenticated requests per token per minute, returning HTTP 429 when exceeded. Buffer no longer publishes the classic rate-limit page, so newer thresholds and the exact header names are not verifiable from a current first-party source. Separately, a profile's queue has a cap on how many updates it can hold, which returns an update-limit error when reached.
Is the classic Buffer API still the one to build on?+
For new work, no. The classic REST API is in maintenance and restricts new app registrations, and its public reference pages now redirect to Buffer's modern platform at developers.buffer.com. That platform adds a GraphQL API and an official hosted MCP server, and is where Buffer directs new integrations.
How does an agent move a post to the front of the queue?+
Calling move_to_top on an update moves it to the top of the profile's queue and recalculates the times for the rest of the queue. It only works on a queued buffer item; if the update is custom-scheduled it returns error code 1027. Reorder and shuffle change the queue order in other ways.
Related

More social API guides for agents

What is Bollard AI?

Control what every AI agent can do in Buffer.

Bollard AI sits between a team's AI agents and Buffer. Grant each agent exactly the access it needs, read or write, profile by profile, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Buffer token.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Buffer
Social Agent
Read scheduled posts ResourceOffReadFull use
Queue a new post ActionOffReadFull use
Share now ActionOffReadFull use
Per-agent access, set in Bollard AI, not in Buffer