A developer platform can have excellent APIs and still make developers do too much archaeology.
Salesforce’s August 25 Headless 360 expansion is a useful case because the announcement goes beyond adding endpoints. Salesforce is exposing business capabilities outside its traditional application surfaces while carrying identity, permissions, metadata, workflows, and business logic along with them. Its Multi-Framework runtime also lets developers build React applications against Salesforce data and Apex without separately managing authentication tokens. The product lesson is broader than Salesforce or AI: developer experience improves when a platform exports capability without exporting all of its historical ceremony.
An API is plumbing, not the whole developer product
An API answers a technical question about how software can call a capability, but a developer product has several more awkward questions to answer. Which capability should I call, what permissions apply, how do I test safely, which errors can I recover from, and what happens when the underlying model changes? Those questions become expensive when every integration team answers them independently, usually after discovering different corners of the same documentation.
Salesforce says its Headless 360 MCP server exposes a small, stable tool surface while the library of underlying Salesforce operations can grow separately. The design choice remains interesting even if MCP eventually disappears from the conversation because the consumer-facing contract can stay smaller than the machinery behind it. Small contracts matter. Every exposed concept becomes something developers may eventually depend on, document, test around, and resist changing later.
I think platform teams sometimes confuse flexibility with making every internal noun externally addressable, which produces a peculiar kind of API-shaped archaeology. Developers end up learning the company’s organizational history because the interface leaks it, including boundaries that may exist mostly because two internal systems were never joined cleanly. A better boundary exposes the durable job and keeps implementation choices behind the wall when customers don’t need them.
Familiar tools count as developer experience
Salesforce Multi-Framework is now generally available and supports React applications running natively on Salesforce, rather than requiring every interface to use a Salesforce-specific framework. Developers can query records with GraphQL, invoke Apex, and read user context through Salesforce APIs while retaining the platform’s authentication and security model. React itself isn’t the important part. It will eventually be supplemented, replaced, or become somebody’s legacy migration project, as successful frameworks have a habit of doing.
The product move is letting developers bring a familiar development model to a platform that historically asked them to learn Lightning Web Components or Aura. Specialized platforms will always contain specialized concepts; some are the reason the platform exists, while others are tollbooths left over from an earlier architecture. Developer experience work should distinguish between them.
If learning a concept gives meaningful control over security, data semantics, transactions, performance, or another durable property, the learning cost may be justified. When the concept mainly exposes an internal implementation boundary, better documentation treats the symptom without removing the tax that every new developer continues paying. This is where developer experience becomes product strategy rather than nicer docs.
Portability creates a compatibility promise
Headless Experience Layer pushes the idea further by separating business logic and data from the rendering surface across several external interfaces. Salesforce’s current beta documentation says HXL components can render on Agentforce, ChatGPT, Claude, and Slackbot, with components rendered natively for each supported channel. Write-once promises deserve suspicion. Surfaces aren’t actually identical, and pretending otherwise usually moves complexity somewhere less visible rather than making it disappear.
A dense desktop table, a Slack interaction, and a conversational card have different space, navigation, latency, and interaction constraints even when they represent the same business capability. Portability works best when the shared layer captures stable intent while each surface retains enough room to behave like itself instead of becoming lowest-common-denominator software.
That tradeoff resembles API migration in reverse. In API deprecation, I argued that the customer dependency is part of the product; a portable platform creates another dependency because customers begin trusting that capabilities will survive movement across frameworks and surfaces. The platform team has to decide which layer owns that promise, and which differences are intentionally allowed to leak through.
For product managers working on developer platforms, I’d test the experience by counting translations rather than counting endpoints, SDK methods, or pages of documentation. How often must a developer translate a business intent into platform-specific terminology, then translate permissions, data models, framework conventions, and deployment rules before useful code runs? Some translation is domain knowledge. The rest is integration tax wearing a developer badge, and adding another quick-start guide doesn’t make the tax disappear.
Good developer platforms don’t merely expose more machinery; they choose which machinery a developer should never have to learn in the first place. The best API may be the part of your architecture developers never discover existed.
Comments
Comments are powered by GitHub Discussions through Giscus.