Salesforce went headless. Social media is next.

A quote that stuck with me

At TDX 2026 last week, Parker Harris — one of Salesforce’s co-founders — asked: “Why should you ever log into Salesforce again?”

It is a strange thing for a co-founder to say about his own product. Twenty-five years of building a SaaS empire around a web console, and now the pitch is that you should not have to open it. He meant it. On April 15 they shipped Salesforce Headless 360: Data 360, Customer 360, Agentforce and Slack all exposed as APIs, MCP tools, and CLI commands. Sixty new MCP tools, thirty coding skills, native integrations into Claude Code, Cursor, Codex, Windsurf. A new Experience Layer that renders cards and approval flows into Slack, ChatGPT, Claude, Gemini, Teams, or any MCP client.

The dashboard did not go away. It just stopped being the thing you have to use.

So what is “headless” now, exactly?

The word has been through a few lives. Headless CMS, headless commerce, headless BI. It used to mean “we decoupled our frontend.” What Salesforce is doing is broader: every capability the platform has is callable from anywhere, with no assumption about who or what is calling it. A human with a CLI. A coding agent inside Cursor. An Agentforce agent. A Slack bot. A piece of glue code in n8n. Same primitives, four different surfaces.

That is a pretty good blueprint for what SaaS looks like over the next few years. The model weights are getting commoditized; the dashboards are not where the value lives. The value lives in the data, the workflows, and the permissions. If your product can only be driven through a browser by a person, you are making an agent-unfriendly SaaS. That category is going to shrink.

Social media marketing is still the least headless corner of SaaS

I have been thinking about this a lot while building Postproxy. Most serious SaaS categories have a credible API-first option. Payments has Stripe. Messaging has Twilio. Data has Supabase and Snowflake. Content has Contentful and Sanity. Design has Figma. Issues have Linear. Every one of those can be driven from code, and now from an agent, without ever seeing the vendor’s UI.

Social media marketing does not have that. The default way to post to Instagram is instagram.com. To LinkedIn, the LinkedIn composer. To TikTok, TikTok Studio. The “management” tools built on top — Hootsuite, Buffer, Sprout, Later — are mostly their own UIs wrapped around the same platform UIs. Buffer has an API again after killing the old one off, but it is clearly a side surface, not the product. Hootsuite’s API exists and nobody recommends building on it.

And the platforms themselves are actively hostile to the headless pattern. Eight OAuth flows, each one slightly different. TikTok’s production audit takes four to eight weeks, with multiple rejection rounds. Instagram forces you through Meta’s Business Manager dance. Every platform has a different media upload protocol, different rate limits, different policy rules. If you are a SaaS founder and you want your agent to post a launch announcement across the channels your customers actually use, you are looking at six months of integration work before anything ships.

We started Postproxy to close that gap. Salesforce shipping Headless 360 just makes the pattern easier to point at.

Postproxy is already built this way

The Postproxy API is one endpoint for every platform:

curl -X POST "https://api.postproxy.dev/api/posts" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "post": { "body": "Launching Headless Orders today." },
    "profiles": ["linkedin", "twitter", "threads"],
    "media": ["https://cdn.example.com/launch.png"]
  }'

No Graph API version negotiation, no platform SDKs, no TikTok audit that you have to run yourself. We do that work once so you do not have to.

There is also a remote MCP server, so any coding agent or conversational agent can publish, schedule, pull stats, reply to comments, without any of our UI in the loop. post_publish, post_publish_draft, queues_create, comments_list, comments_create, post_stats. All the same verbs you would use in a curl call, typed and callable by Claude Code or Cursor or ChatGPT or whatever else your team has open.

The dashboard still exists. If a human wants to review a draft, approve a queue, look at analytics, it is there. But nothing in the product requires them to use it. That was deliberate from day one. We built Postproxy because we needed to publish from our own pipelines, and pipelines do not open browsers. Everything we built, we built from the outside in.

Where this plugs into an agentic stack

If you are building on top of Salesforce’s new world, or any agentic stack really, social publishing is the part that still tends to fall back to a human opening LinkedIn. A few patterns that stop that from happening:

A product manager in Cursor types something like “draft a four-post campaign for the Headless Orders launch on April 28, split across LinkedIn and X.” The coding agent reads the release date from Salesforce via its MCP, drafts the copy, and creates a scheduled queue in Postproxy. The PM reviews the drafts in a Slack thread. They ship.

A headless CMS — Contentful, Sanity, Strapi — fires a webhook when an editor publishes an article, and that webhook calls Postproxy to cross-post across every connected channel. The whole thing is twenty lines of serverless code.

An agent polls comments on recent posts via comments_list, classifies them, and escalates anything it is not confident about into a human channel. Replies go out through comments_create. The support team never has to open Instagram to respond to a comment again.

None of these require an agent to know that Instagram’s Graph API is different from LinkedIn’s UGC endpoint. That is the whole point of having a headless layer in between.

The pattern is obviously going to repeat

Stripe shipped MCP tools. Linear shipped MCP tools. Notion, GitHub, Figma — all shipped them in the last year or so. The coding-agent-native SaaS stack is forming in public, and the categories that do not have a clean API primitive get left out of it. Social media sat in that awkward spot for a long time because “post to every platform” is genuinely hard infrastructure. Eight OAuth flows, eight upload protocols, constantly shifting platform rules.

I think that awkward spot is closing. Postproxy is the missing primitive for this category — posts, queues, comments, stats, all callable over HTTP and MCP and, if you prefer, your shell. If you are already wiring up Agentforce or building on top of any of the MCP-first platforms, connecting Postproxy is about an afternoon of work.

If you want to try it: create an account, connect your accounts, point your agent or workflow at the API or the MCP server, and see what your pipeline looks like when publishing is no longer the step that needs a human.