In May, we launched Buffer's GraphQL Public API, enabling developers to build on Buffer. It's a strongly typed, GraphQL-first API with an MCP server, a CLI, and managed OAuth, running on the same infrastructure as our own apps. With it in place, we're winding down the older API it replaces.
We're retiring Buffer's legacy REST API on February 1, 2027. After that date, requests to legacy endpoints will no longer return data; therefore, all clients who are still using the legacy REST API are encouraged to start the migration process.
How the REST API came to be
We first launched Buffer's public API back in 2012, with a small but mighty group of around 15 integrations like Pocket, IFTTT, and other early web favorites. It was built on REST, the standard at the time, and let developers schedule posts and manage profiles. By 2019, more than 47,000 clients were building on it.
Then the landscape shifted. Following privacy scandals like Cambridge Analytica, social platforms tightened their terms of service and data privacy requirements. As a result, we wanted to ensure that our users’ data is safe and restrict how our API could be used. Around the same time, our own architecture was evolving: we unified our once-separate products under "One login, All of Buffer" and began consolidating everything onto a single, modern GraphQL API. In October 2019, we closed registration for new legacy apps - we knew we couldn't offer the developer experience we (and our partners) wanted without a much bigger investment.
That investment became Buffer's GraphQL Public API. Rather than maintain two API stacks with separate tooling - a heavy lift for a team our size - we've committed to one API that powers both our own apps and yours. Retiring the legacy REST API is the final step in that transition.
What's changing
- The legacy REST API will be fully retired on February 1, 2027. Requests to legacy endpoints will no longer return data.
- This affects anyone still calling the legacy REST API endpoints.
- New client creation on the legacy API is already closed.
- Deprecation and sunsetting signals will be added to the legacy endpoints: standard
DeprecationandSunsetheaders plus aLinkheader pointing to the migration guide. - Two brownouts are planned before sunset: November 11 and December 9, 2026. Short scheduled interruptions where legacy requests will temporarily error out. All legacy clients who haven’t completed the migration will be notified about the brownouts ahead of time.
How to migrate to the new API
We've completed a thorough feature-parity analysis between the new and legacy APIs, and nearly every legacy capability has a direct equivalent in the GraphQL API.
Familiar concepts simply have new names - profiles are now channels, and updates are now posts. A few things also work differently under GraphQL, and they're worth knowing before you migrate:
- Scheduling is per-post. Rather than managing recurring time slots on a profile, you decide how each post is scheduled: add it to the queue, set a specific time, or publish immediately.
- Posts are created one channel at a time. Where the legacy API accepted an array of profile IDs, you now send one request per channel.
- Pagination is cursor-based instead of page-and-offset, so it stays reliable even as your queue changes.
- Errors are returned as typed fields in the response body, rather than as HTTP status codes.
For the full endpoint-by-endpoint mapping and code examples, see the REST API migration guide. If you hit a gap that's blocking your migration, reach out to the Buffer team - we want to help you and ensure the migration goes smoothly.
If you need help migrating
If you maintain a legacy integration and need help migrating, reach out to us on Discord or send us a message at developersupport@buffer.com - we can walk through your migration or help resolve a gap you hit. If a capability you rely on doesn't have an equivalent, let us know, and we will work with you to find a solution.
from Buffer Resources https://ift.tt/6Z7Bw8u
In May, we launched Buffer's GraphQL Public API, enabling developers to build on Buffer. It's a strongly typed, GraphQL-first API with an MCP server, a CLI, and managed OAuth, running on the same infrastructure as our own apps. With it in place, we're winding down the older API it replaces.
We're retiring Buffer's legacy REST API on February 1, 2027. After that date, requests to legacy endpoints will no longer return data; therefore, all clients who are still using the legacy REST API are encouraged to start the migration process.
How the REST API came to be
We first launched Buffer's public API back in 2012, with a small but mighty group of around 15 integrations like Pocket, IFTTT, and other early web favorites. It was built on REST, the standard at the time, and let developers schedule posts and manage profiles. By 2019, more than 47,000 clients were building on it.
Then the landscape shifted. Following privacy scandals like Cambridge Analytica, social platforms tightened their terms of service and data privacy requirements. As a result, we wanted to ensure that our users’ data is safe and restrict how our API could be used. Around the same time, our own architecture was evolving: we unified our once-separate products under "One login, All of Buffer" and began consolidating everything onto a single, modern GraphQL API. In October 2019, we closed registration for new legacy apps - we knew we couldn't offer the developer experience we (and our partners) wanted without a much bigger investment.
That investment became Buffer's GraphQL Public API. Rather than maintain two API stacks with separate tooling - a heavy lift for a team our size - we've committed to one API that powers both our own apps and yours. Retiring the legacy REST API is the final step in that transition.
What's changing
- The legacy REST API will be fully retired on February 1, 2027. Requests to legacy endpoints will no longer return data.
- This affects anyone still calling the legacy REST API endpoints.
- New client creation on the legacy API is already closed.
- Deprecation and sunsetting signals will be added to the legacy endpoints: standard
DeprecationandSunsetheaders plus aLinkheader pointing to the migration guide. - Two brownouts are planned before sunset: November 11 and December 9, 2026. Short scheduled interruptions where legacy requests will temporarily error out. All legacy clients who haven’t completed the migration will be notified about the brownouts ahead of time.
How to migrate to the new API
We've completed a thorough feature-parity analysis between the new and legacy APIs, and nearly every legacy capability has a direct equivalent in the GraphQL API.
Familiar concepts simply have new names - profiles are now channels, and updates are now posts. A few things also work differently under GraphQL, and they're worth knowing before you migrate:
- Scheduling is per-post. Rather than managing recurring time slots on a profile, you decide how each post is scheduled: add it to the queue, set a specific time, or publish immediately.
- Posts are created one channel at a time. Where the legacy API accepted an array of profile IDs, you now send one request per channel.
- Pagination is cursor-based instead of page-and-offset, so it stays reliable even as your queue changes.
- Errors are returned as typed fields in the response body, rather than as HTTP status codes.
For the full endpoint-by-endpoint mapping and code examples, see the REST API migration guide. If you hit a gap that's blocking your migration, reach out to the Buffer team - we want to help you and ensure the migration goes smoothly.
If you need help migrating
If you maintain a legacy integration and need help migrating, reach out to us on Discord or send us a message at developersupport@buffer.com - we can walk through your migration or help resolve a gap you hit. If a capability you rely on doesn't have an equivalent, let us know, and we will work with you to find a solution.
Comments
Post a Comment