Home/Resources/Architecture
Architecture9 min read

Headless CRM: Salesforce as an API-first engine.

Keep Salesforce as your system of record and business logic — and surface it through your own web, mobile, portal and kiosk experiences over APIs. Here's what headless CRM actually means, where it pays off, and where it doesn't.

Key takeaways
  • Headless CRM decouples the experience layer from Salesforce's data model and logic.
  • Salesforce becomes an API-first backend — REST, GraphQL, Connect API and Data Cloud do the talking.
  • It pays off when you need branded, high-volume or multi-channel front-ends — not for internal back-office work.
  • The hard parts are auth, API limits, caching and keeping one source of truth.

What "headless" actually means

A traditional Salesforce implementation couples three things in one place: the data model, the business logic and the user interface. Headless CRM splits the front-end off. Salesforce stays the system of record and the rules engine, but the screens your customers and staff use live somewhere else — a React web app, a native mobile app, a customer portal, a kiosk, even another product's UI. Those front-ends talk to Salesforce purely over APIs.

It's the same idea the commerce world adopted with headless commerce: one composable backend, many decoupled experiences. The CRM becomes a service that any channel can call, rather than a place people have to log into.

The Salesforce building blocks

Salesforce is well suited to this because it exposes its engine through a deep API surface. A headless architecture typically leans on a combination of:

  • REST & SOAP APIs — CRUD on standard and custom objects, the workhorse for most reads and writes.
  • GraphQL API — fewer round-trips for front-ends that need shaped, nested data in one call.
  • Connect API — higher-level experience data (feeds, communities, commerce) without rebuilding it.
  • Apex REST & invocable services — your own endpoints that wrap complex business logic into a clean contract.
  • Platform Events & Change Data Capture — push changes outward so front-ends and downstream systems stay in sync.
  • Data Cloud — a real-time data backbone that unifies profiles and events across channels and feeds them back to every experience.
  • MuleSoft / API gateway — an integration and governance layer in front, when you have many consumers.

Authentication is usually OAuth 2.0 — Client Credentials or JWT bearer flows for server-to-server, and the right grant for user-facing apps. Salesforce stays the identity-aware policy boundary; the front-end never sees more than its scope allows.

When headless is the right call

Headless is a deliberate trade, not a default. It earns its keep when:

  • You need a fully branded, pixel-controlled experience that the standard Salesforce UI can't deliver.
  • You're serving many channels — web, mobile, partner portals, in-store — from one source of truth.
  • You expect high, public-facing traffic where you want a fast edge layer in front of the CRM.
  • You're embedding CRM capability inside another product rather than sending users into Salesforce.
  • You want the freedom to evolve the front-end independently of the platform release cycle.

When it isn't

For internal sales and service teams, the standard Lightning experience plus configuration is faster to build, cheaper to run and easier to maintain. Going headless there means rebuilding navigation, list views, reporting and security UI that Salesforce already gives you for free. If the only goal is "we don't like the look", that's rarely worth a custom front-end and a permanent API integration to own.

The parts that are genuinely hard

The promise is clean; the engineering is where projects succeed or fail. The recurring challenges:

  • API limits & performance — you have to design for governor and request limits with caching, bulkification and a read model, not hammer the org per page view.
  • One source of truth — logic must stay in Salesforce, not get quietly re-implemented in the front-end where it drifts out of sync.
  • Auth & security — token lifecycle, scope, field-level security and audit have to be enforced server-side, never trusted to the client.
  • Caching & freshness — an edge/read layer keeps experiences fast, but needs event-driven invalidation so users don't see stale data.
  • Observability — when the UI and the engine are separate systems, you need tracing across the boundary to debug anything.

How we approach it

We treat Salesforce as a product with a contract. We define the API surface first — the objects, services and events the front-end is allowed to use — wrap business logic in versioned Apex/GraphQL endpoints, put a caching and integration layer in front where the load justifies it, and use Data Cloud when profiles and events need to be unified in real time. The result is one governed source of truth with as many decoupled, branded experiences on top as the business needs.

Thinking about headless CRM?

We'll tell you honestly whether it's the right move — and design the API layer if it is.

Talk to the builders about headless CRM