Postiz and Buffer: Two Shapes of Publishing API

There are 18 providers in the catalog carrying both the Publishing and Social-Media tags. Two of them are worth putting side by side, because they solve the same problem — get a post onto a social channel on a schedule — and disagree about almost everything else.

Postiz scores 69.4, exemplar. Buffer scores 64.3, strong. Five points apart on the composite, and nearly opposite in shape.

The facets disagree in both directions

The 31-point spread on operational transparency is the widest gap between them, and the 19-point spread on contract quality explains itself: Postiz publishes OpenAPI, Buffer publishes GraphQL. A GraphQL schema is a real contract, but it does not carry per-operation metadata the way a specification does, and the rubric reads that difference honestly rather than pretending the two are interchangeable.

Buffer takes commercial clarity by 21 points. Pricing and plans are unambiguous, and it ships a Sandbox and a published Deprecation policy — two artifacts Postiz does not have at all.

What Postiz does that Buffer does not

Postiz publishes an agentic-access profile: 248 operations classified, 143 acting, 122 flagged human-in-the-loop. Every one of its 20 public operations carries an action class and a consequence, so an integrator can filter consequence=read and find the safe surface before pointing anything autonomous at it. Buffer publishes no agentic-access artifact.

The MCP contrast is sharper still. Both ship first-party MCP servers and first-party agent skills. But Postiz’s 11 tools enumerate — schedulePostTool, integrationList, triggerTool, and notably integrationSchema, which hands back a platform’s character limits and required settings so an agent can check the rules before composing rather than failing on submit. An anonymous tools/list against Buffer’s server returns HTTP 401, so the catalog records it as gated rather than guessing. The server is real; the tool list is not readable without a key.

Postiz also describes its events. Webhooks plus an AsyncAPI specification means you can know a post published without polling. Buffer’s event_surface_described is false.

What Buffer does that Postiz does not

Buffer offers OAuth 2.0 with PKCE and dynamic client registration. Postiz is API-key only. If you are publishing on behalf of other people’s accounts, that is not a preference, it is a requirement.

And Buffer is doing the unglamorous thing almost nobody in this cohort does: it announced an end date. The legacy REST API retires February 1, 2027, with GraphQL as the path forward, documented alongside a roadmap and a changelog. Buffer’s contract governance still only scores 18.2 — but it edges Postiz, and it got there by telling people what is going away and when.

Where both of them fail

reversibility_documented: false on both. dry_run_mode: false on both. idempotency: false on both.

These are publishing APIs. The entire risk surface is posting the wrong thing to a live audience, and neither provider documents how to undo it, how to preview it, or what happens when a retried create runs twice. That is not a Postiz problem or a Buffer problem. Across all 18 providers in the Publishing and Social-Media cohort, only two document reversibility at all, and not one offers a dry-run mode.

Both providers are gated down from agent-native to agent-ready on the strength of everything else they do right. The thing standing between them and the top band is the same thing: an agent can be trusted to publish only if it can be told how to take it back.

Which one

Take Postiz for the contract, the channel breadth, the event surface, and the option to run the whole thing yourself. Take Buffer for multi-tenant OAuth, a sandbox to test against, and a vendor that publishes deprecation dates.

Full profiles, with every artifact and the evidence behind them, at apis.io/providers/postiz/ and apis.io/providers/buffer/.