Day 1/15 — What Is Salesforce Headless 360 and Why Does It Matter?

Neha is an Account Executive whose biggest customer is Acme Global Tech. Before a call with Acme's VP of Sales, Priya Sharma, she needs three things: the open deals, the high-priority support case, and when anyone last spoke to the account. Today that means opening Salesforce, clicking through four tabs and copying numbers into her notes. She would rather ask her AI assistant, in the window she already has open, and get an answer that shows exactly what she is allowed to see and nothing more.

Her admin, Arjun, has heard that Salesforce now supports this through Salesforce Headless 360 (now called AIforce). He has also met a third name, the Headless Toolkit, read blog posts that contradict each other, and found a Setup page of Model Context Protocol (MCP) servers that he has never switched on.

This series is for both of them. Over 15 days we go from "what is this?" to a working, secure AI assistant that reads and writes Salesforce data as the signed-in user. Today is the map.

By the end of today you will know what Headless 360 is, which parts are generally available and which are beta, and you will have made your first request to a Salesforce hosted MCP server without logging in.

There is no recap on Day 1, so here is the route instead. The fifteen days fall into five stages:

1. Understand it (Days 1–4): what Headless 360 is, its architecture, how MCP works, and switching on Salesforce's hosted MCP servers.
2. Connect it (Days 5–7): OAuth with an External Client App, connecting Claude, and exploring the tools you get.
3. Build with it (Days 8–10): reading data in plain language, writing it safely, and a first repeatable workflow.
4. Architect it (Days 11–14): security, custom tools in Apex and Flow, agentic architecture, and production concerns.
5. Build the project (Day 15): a complete headless AI assistant in Next.js that talks to Salesforce through Claude.

Each day has one concept, one hands-on result and one section on what can go wrong. Every Setup path, tool name and status claim was checked against Salesforce and Anthropic documentation on the date in the Sources box, which matters because Salesforce is moving quickly here. The code for the later days lives in a companion repository, salesforce-headless-360, including a script that creates the Acme records in your test org.

What Salesforce announced at TDX 2026

On April 15, 2026, at its TDX developer conference, Salesforce published "Introducing Salesforce Headless 360. No Browser Required." The subheading is the whole idea in one line: "Everything on Salesforce is now an API, MCP tool, or CLI command, and agents can use all of it."

The official definition is a little longer. Salesforce Headless 360 is "the capabilities your agents need most, exposed as an API, MCP tool, or CLI command so humans and agents can build, act, and deliver experiences on any surface."

The launch article quotes a question Parker Harris asked out loud the month before: "Why should you ever log into Salesforce again?" It is a provocative line from a company most people know as a browser tab, and it is the right question, because the people who use Salesforce data increasingly work somewhere else.

The announcement grouped the launch into three innovations:

• "New MCP tools and coding skills that give your coding agent full access to your platform"
• "A new experience layer that renders rich, native interactions across every surface, from Slack to Voice to WhatsApp"
• "New tools that give you control over how agents behave in production, before launch and after"

A month later, Salesforce's developer blog put numbers on the surface area: "60+ MCP tools, 30+ coding skills, 4,000+ existing APIs, and 220+ CLI commands," all "accessible to any authenticated caller that your trust layer authorizes." That last clause is the part I would underline. Headless 360 is not a new back door. It is the existing platform, with its existing permissions, made reachable from more places.

Since then, Salesforce opened a beta of the Headless 360 MCP Server in July and made the Data 360 MCP Server and Salesforce Multi-Framework generally available in August.

From Headless 360 to AIforce: what the rename changed

If you searched for Headless 360 recently, you probably also saw the word AIforce. Salesforce's release notes put it plainly: "As of September 4, 2026, Headless 360 has been rebranded to AIforce. During this transition, you may see references to Headless 360 in our application and documentation. While the name is new, the functionality and content remains unchanged."

The name changed and the technology did not. A Salesforce knowledge article from September 17 explains how the new names fit together: "While AIforce is the concept of bringing all your Salesforce context to the interface where you work, Headless Toolkit provides the functionality to make it a reality."

At Dreamforce, Salesforce described AIforce as "a live interface layer that brings the full power of Salesforce to wherever people and agents work," launching with Claudeforce, Slackforce and Agentforce Coworker. The same announcement says "AIforce is powered by the Headless Toolkit," which gives builders "MCPs, APIs, plug-ins, skills, and developer tools." The Help article that welcomes you to AIforce is blunt about what it is not: "AIforce isn't a single product or tool."

In practice you will meet both names for a while. Salesforce's documentation still tells you to activate a beta server called headless-360 in Setup, the Salesforce in Claude documentation calls it the "Headless360 (H360) MCP Server", and most tutorials say Headless 360. So this series carries both names in its title. I write "Headless 360" by default, as the documentation does, and "AIforce" when I mean the current name in Salesforce's announcements and Help.

Headless, explained without jargon

A "headless" system separates the back end (data, rules and business logic) from the "head" people look at. For most of Salesforce's history the head was Lightning Experience, running in a browser.

Nothing about Lightning goes away. What changes is that the same platform is now a first-class back end for clients that are not Lightning:

• an AI assistant such as Claude, asking questions on a user's behalf;
• a coding agent such as Claude Code, reading your org's metadata while it writes Apex;
• a web or mobile app you build yourself, where Salesforce is the system of record behind your own interface;
• an automation that runs a Flow or an Apex action without anyone opening a page.

What stays the same matters more. Salesforce lists four things "enforced on every API call, every MCP tool invocation, and every CLI command": identity, access, invocation scope and governance, where "Validation rules, triggers, approval chains, and governor limits all fire regardless of entry point." A validation rule from 2019 still protects your data when an agent creates the record in 2026.

The caveat is that a headless client works faster and at larger scale than a person clicking, and it can be tricked by the data it reads. That is why Days 9, 11 and 14 cover confirmation, least privilege and monitoring.

The building blocks

Headless 360 is a set of building blocks, some old and some new in 2026. It helps to know which is which before we touch Setup.

A hosted MCP server, in Salesforce's words, "is a Salesforce-managed endpoint that exposes your org's logic and assets — data, flows, Apex actions, queries, and more — to any AI client that speaks MCP. Salesforce handles hosting, authentication, and permission enforcement automatically." You do not deploy anything. You switch a server on in Setup, create an External Client App, and point a client at a URL. The general availability announcement covers Enterprise Edition and above, and Salesforce's own wiki adds that Developer Edition orgs can use them too. That is what makes this series possible without a production org.

The External Client App is where older tutorials often go wrong. Salesforce's documentation is explicit: "Use an External Client App to connect an MCP client to a Salesforce org. Connected Apps aren't supported." Since Spring '26, creating new connected apps is disabled by default in every org. If a guide tells you to create a Connected App for MCP, it is out of date; the first version of this very article did, and this rewrite fixes it.

Where MCP fits

MCP is an open standard for connecting AI applications to external tools and data. An AI application, the host, runs an MCP client for each server it connects to. The server publishes tools: named functions with a description and an input schema that the model can decide to call. The current revision of the specification is dated 2026-07-28.

In Headless 360 terms, Salesforce runs the MCP servers and your AI application is the client. When Neha asks Claude about Acme, Claude reads the tool list from sobject-all, decides to call soqlQuery with a query it writes, and Salesforce runs that query as Neha. There is no language model on Salesforce's side of a standard hosted server. Salesforce's own FAQ says the processing "is completely deterministic," and all the reasoning happens in the client.

Salesforce distinguishes "two kinds of MCP tools": tools for coding agents, used by developers building software, and tools for business agents, where the consumer is "an agent serving an end user." This series covers both, mostly the second. Day 3 explains the protocol and Day 7 opens up the tools.

Why it matters, by role

For developers, the glue code shrinks. You expose business logic once, as an invocable Apex method or an autolaunched Flow, and every MCP client can use it with the user's permissions. Days 10 and 15 build an app of your own that calls the same hosted servers through Claude's API (an experiment, because no document yet confirms that pairing), and coding agents get org context through the Salesforce CLI, the DX MCP Server and agent skills.

For admins, there are new Setup surfaces to own. MCP servers are "disabled by default and require explicit administrative action to enable." The External Client App decides which users may connect and how long their sessions last. Permission sets decide what the agent can actually do, because the agent is the user. Salesforce's beta announcement puts it simply: "If you can't do it in Salesforce, your agent can't do it through the MCP server."

For architects, Headless 360 adds an entry point without adding a new security model. The decisions are familiar ones in new places: which server to expose (read-only or full access), which client to trust, how tokens are stored, where confirmation happens, and how usage is logged and paid for. On cost, Salesforce's documentation states that hosted MCP servers "are intended only for customers with Flex Credits and you may be billed for server usage." A September knowledge article says Salesforce is "Targeting November" for a new billing model and for agent registration. Developer Edition orgs, sandboxes and scratch orgs don't incur that metering. Day 14 comes back to this with whatever Salesforce has published by then.

Hands-on: meet your first hosted MCP server

We connect Claude on Day 6, after switching the servers on (Day 4) and creating an External Client App (Day 5). You can learn something useful today without an org, because every protected MCP server publishes a small public document that tells clients how to authenticate. MCP calls this OAuth 2.0 Protected Resource Metadata (RFC 9728), and the specification requires MCP clients to use it to find the authorization server.

Step 1: read the server's metadata

Open a terminal and run:

curl https://api.salesforce.com/.well-known/oauth-protected-resource/platform/mcp/v1/platform/sobject-all

You should see this (formatted here for reading):

{
  "resource": "https://api.salesforce.com/platform/mcp/v1/platform/sobject-all",
  "authorization_servers": [
    "https://login.salesforce.com"
  ],
  "scopes_supported": [
    "mcp_api", "refresh_token"
  ]
}

Three fields, three lessons:

• resource is the server's own URL. Hosted servers live on api.salesforce.com, not on your org's My Domain. The standard URL is the same for every org, so the token you present is what ties a request to your org and your user. Salesforce also offers a My Domain form of the URL, which we cover on Day 4.
• authorization_servers says where users sign in. For production and Developer Edition orgs that is login.salesforce.com. Sandbox and scratch orgs use the /sandbox/ form of the server URL, which we cover on Day 4.
• scopes_supported lists exactly two OAuth scopes: mcp_api and refresh_token. On Day 5 you will select exactly these two on your External Client App. Older posts from the beta period list api and sfap_api; those were beta scopes and they "will not work with the GA service."

Step 2: knock on the door without a key

curl -i -X POST -H "Content-Type: application/json" -d '{}' \
  https://api.salesforce.com/platform/mcp/v1/platform/sobject-all

The server answers 401 with the body {"errors":[{"message":"JWT Token is required"}]}. Two things are worth noticing. The server refuses anonymous calls, and it asks specifically for a JWT. That is why, on Day 5, you will switch on the External Client App setting Issue JSON Web Token (JWT)-based access tokens for named users. Salesforce requires JWT access tokens so the MCP server can validate them without a separate call back to Salesforce on every request.

Step 3: the same check in TypeScript

The rest of the series leans on TypeScript, so here is the same check as a small script. It runs on any current Node.js, but the series standard is 22.19 or later, because MCP Inspector needs it on Day 3.

// check-mcp-server.ts: what a Salesforce hosted MCP server tells the world before you log in.
// Run with Node.js 22.19+:  npx tsx check-mcp-server.ts
const SERVER = "https://api.salesforce.com/platform/mcp/v1/platform/sobject-all";

type ProtectedResourceMetadata = {
  resource: string;
  authorization_servers: string[];
  scopes_supported?: string[];
};

async function main(): Promise<void> {
  // RFC 9728: the metadata lives at /.well-known/oauth-protected-resource + the server's path.
  const server = new URL(SERVER);
  const metadataUrl = `${server.origin}/.well-known/oauth-protected-resource${server.pathname}`;

  const metadataResponse = await fetch(metadataUrl);
  if (!metadataResponse.ok) {
    throw new Error(`Metadata request failed with HTTP ${metadataResponse.status}`);
  }
  const metadata = (await metadataResponse.json()) as ProtectedResourceMetadata;
  console.log("Resource:  ", metadata.resource);
  console.log("Sign in at:", metadata.authorization_servers.join(", "));
  console.log("Scopes:    ", metadata.scopes_supported?.join(" ") ?? "(none listed)");

  // The server itself refuses anonymous calls.
  const probe = await fetch(SERVER, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: "{}",
  });
  console.log("No token:  ", probe.status, await probe.text());
}

main().catch((error: unknown) => {
  console.error(error);
  process.exit(1);
});

"""What a Salesforce hosted MCP server tells the world before you log in (Python 3.10+, standard library)."""
import json
import urllib.request
from urllib.error import HTTPError
from urllib.parse import urlsplit

SERVER = "https://api.salesforce.com/platform/mcp/v1/platform/sobject-all"

def main() -> None:
    parts = urlsplit(SERVER)
    metadata_url = f"{parts.scheme}://{parts.netloc}/.well-known/oauth-protected-resource{parts.path}"
    with urllib.request.urlopen(metadata_url, timeout=20) as response:
        metadata = json.load(response)
    print("Resource:  ", metadata["resource"])
    print("Sign in at:", ", ".join(metadata["authorization_servers"]))
    print("Scopes:    ", " ".join(metadata.get("scopes_supported", [])))

    probe = urllib.request.Request(
        SERVER, data=b"{}", headers={"Content-Type": "application/json"}, method="POST"
    )
    try:
        urllib.request.urlopen(probe, timeout=20)
    except HTTPError as error:
        print("No token:  ", error.code, error.read().decode())

if __name__ == "__main__":
    main()

Swap sobject-all for sobject-reads in either script and you will see the same two scopes. Hosted servers share one sign-in model: an External Client App grants access to hosted MCP as a whole, not to one server. That is convenient, and on Day 11 we look at what it means for security.

Step 4: get ready for the next 14 days

Set these up now so that Day 4 is about Salesforce, not installing things:

1. A Salesforce Developer Edition org you are happy to break. Every Developer Edition org includes Salesforce Hosted MCP Servers "at no cost."
2. A Claude account, and optionally Claude Desktop. The Free plan allows one custom connector, which is enough to start.
3. Claude Code, for the coding-agent days and for extra servers.
4. Node.js 22.19 or later and a current Salesforce CLI (sf update).

What can go wrong

Most early mistakes with Headless 360 are assumptions carried over from older tutorials or from the beta. Here are the common ones, and the day that deals with each.

A note on trust

The platform gives you the mechanisms but doesn't make decisions for you. A model that can call deleteSobjectRecord will eventually be asked to, sometimes by text hidden in a record it just read. From Day 9 on, every write in this series goes through an explicit confirmation step, and from Day 11 on we design as if the model is the least trustworthy component in the system.

Today's checklist

• I can explain Salesforce Headless 360 in one sentence, and why it is now also called AIforce.
• I know which parts are generally available (hosted MCP servers) and which are beta (the Headless 360 MCP Server).
• I ran the metadata check and saw mcp_api and refresh_token.
• I saw the 401 that a hosted server returns without a token.
• I have a Developer Edition org for this series, not a production org.
• Claude, Claude Code, Node.js 22.19+ and a current Salesforce CLI are installed.

Frequently asked questions

Is Salesforce Headless 360 the same as AIforce?

Yes. Salesforce renamed Headless 360 to AIforce on September 4, 2026, with unchanged functionality. AIforce is the concept; the Headless Toolkit is the MCP servers, APIs, plug-ins, skills and developer tools that deliver it.

Do I need to buy something to use Headless 360?

Not to learn it: Developer Edition orgs include hosted MCP servers at no cost. For production, Salesforce says hosted MCP servers are intended for customers with Flex Credits and usage may be billed, with new metering targeted for November 2026.

Do I need Agentforce to use the hosted MCP servers?

No. Salesforce lists Claude, ChatGPT, Cursor, Postman and Agentforce Vibes as tested clients, and says other clients that support OAuth 2.0 Authorization Code with PKCE should also work. This series uses Claude.

Can an AI assistant see all my Salesforce data?

No. Hosted MCP tool calls run with the signed-in user's object permissions, field-level security and sharing rules, and the audit trail records that user.

What is the difference between hosted MCP servers and the Headless 360 MCP Server?

The standard hosted servers, such as sobject-all, are generally available and expose a fixed set of tools per server. The Headless 360 MCP Server is a beta with four generic tools (Discover, Describe, Dispatch and Dispatch Read-Only) that search and run a growing library of Salesforce operations.

Can I follow the series with a sandbox instead of a Developer Edition org?

Yes, with two differences. Sandbox and scratch orgs use server URLs that contain /sandbox/. External Client Apps can't be created in a scratch org's Setup, and local ones aren't copied when a sandbox is refreshed. A Developer Edition org avoids both issues.

What's next

Tomorrow we zoom out before we zoom in. Day 2 follows a single request from Neha's assistant to Salesforce and back: through the client, the identity layer, the MCP server and the platform. On the way we sort out what runs as whom, and when to use MCP instead of calling the REST or GraphQL API directly.