The API Surface

The kernel exposes everything through APIs; the CLI is a client of them, not a separate path. Because an org can run fully headless — ignore the platform’s own UI and drive everything from a customer’s own infrastructure — the API surface is a first-class product, not an afterthought. A customer who wants nothing but the engine interacts with exactly these families.

The surface separates into distinct families, each individually documentable. This page defines the families and their boundaries; the endpoint-by-endpoint reference (verbs, paths, payloads, errors) is developer documentation, in the spirit of a mature platform’s API reference, and lives on the developer-docs surface rather than here.

The families the platform builds first

Four families make headless operation fully possible, and they are the ones to build and document first.

Data API

Record create, read, update, delete, plus query and describe, over metadata-defined objects. This is the headless workhorse — the answer to “how does a customer perform CRUD on their data without the platform’s UI.” Its minimal shape:

• Create — POST /data/{object} with a field map.
• Read — GET /data/{object}/{id}.
• Update — PATCH /data/{object}/{id}.
• Delete — DELETE /data/{object}/{id}.
• Upsert by external id — PATCH /data/{object}/{externalIdField}/{value}.
• Query — GET /data/query?q=<query> in a SOQL-style query language, with cursor paging for large result sets.
• Describe — GET /data/{object}/describe returns the object’s fields and types; a global list enumerates all objects.

Everything else in this document is an optimization on top of these verbs.

Metadata API

Deploy and retrieve source-format metadata, transactionally and validated as a unit — the existing deploy primitive the CLI drives. It is bulk and transactional: it moves whole packages of metadata between environments and either applies them completely or not at all. Already built; described on the Kernel page.

Tooling API

Fine-grained, synchronous, per-component metadata operations — create or edit a single field, layout, or object, and query over metadata — for the CLI, the VS Code extension, and any dev tool. It is the interactive sibling of the Metadata API: interactive editing means “change this one component and get an answer now,” which a full transactional package deploy is too coarse and too slow to serve. Both exist because they do different jobs — surgical single-component edits versus bulk package deploys.

Event API

One modern streaming API — subscribe and publish over the platform’s event system, with durable replay and flow control, on an efficient binary transport. It hooks directly into the outbox/effects event mechanism. Deliberately a single, current-generation API: the platform does not ship a second, legacy long-poll streaming API beside it, because a greenfield platform gains nothing from the older twin.

The families deferred

These are additive; none of them blocks headless use, which the four above already fully enable. Each is built when it earns its place.

• Bulk Data API — asynchronous, high-volume load and extract for migrations and ETL. The regular Data API serves small, real-time work; past a few thousand records, bulk processing is the right tool. Deferred until customers run migrations at volume — additive, so deferring costs nothing.
• UI API — returns data and layout metadata composed together, so a headless client can ask “give me everything needed to render this record’s page” and receive fields, layout, and values in one response. This is the highest-value deferred family for a metadata-driven platform, because it is a natural externalization of what the kernel already does internally — interpret layout metadata to render a surface. It is deferred, not foundational, only because the Data API plus describe already let a headless client reconstruct any surface manually; the UI API is the convenience that makes headless UI-parity trivial.
• GraphQL API — a field-precise, multi-object query interface over the same data model, for clients that want to request exactly the fields they need in one round-trip.
• Composite / Batch API — bundles multiple, optionally dependent Data API calls into a single round-trip; added when call chattiness becomes the bottleneck.
• Custom endpoints — developer-defined server endpoints (via edge functions), the analog of platform-hosted custom REST endpoints.

What the platform deliberately does not build

• No SOAP API. It is legacy; adopting it would be building backwards onto technology the platform is deliberately leaving behind.
• No second, legacy streaming API. The single modern Event API subsumes the older long-poll model entirely.
• No per-industry or product-cloud API catalog. A mature platform’s API index is dominated by vertical-cloud and product APIs (commerce, marketing, analytics, and so on). Those are applications built on the platform, delivered here as packages and org shapes — not platform primitives. The platform exposes the primitives; the verticals are metadata on top of them.

One surface, uniform rules

Every family above is the same authenticated, access-checked surface described on the Kernel page. Each request carries a session; every read and write, including metadata reads, passes through the access engine; and the CLI is a client of these APIs rather than a separate door. The families differ in shape, transport, and payload — never in how authentication or access control apply. That uniformity is what lets a headless customer trust that the API path enforces exactly what the UI path would.