Skip to main content
The API reference is an automatically derived catalog of your Salesforce org’s REST surface. Instead of hand-maintaining a list of endpoints that drifts out of date, LivingContext derives the catalog from your org’s metadata, generates OpenAPI specs for you, and proposes updates when the underlying implementation changes.

​
What’s in the catalog

The catalog covers both directions of traffic:

Inbound

APIs your org exposes: Apex REST resources your team has built, plus the standard Salesforce Data API.

Outbound

External services your org calls: the targets of your Named Credentials.
This gives integration engineers, architects, and auditors one place to answer “what can call us, and what do we call?” — without spelunking through Setup. See Salesforce integration for how org metadata reaches LivingContext.

​
Specs generate themselves

You don’t have to create the catalog by hand:
1

Connect Salesforce

Connecting an org kicks off the first metadata sync automatically — there is nothing to trigger manually. See Salesforce integration.
2

Every sync fills the gaps

After each metadata sync, LivingContext looks for derived endpoints that have no reference yet — Apex REST classes and Named Credentials — and generates a skeleton OpenAPI spec for each one.
3

Specs land in your repo

Each generated spec is committed to your docs repository as a YAML file and registered in the API reference. Git is the system of record — the spec is versioned, diffable, and reviewable like any other doc.
Auto-generation is deliberately incremental — around 25 specs per sync — so a large org fills in over a few sync cycles rather than flooding your repo in one commit. Anything left over drains on the next sync.
You can also work manually from the API Reference page header:
  • Generate from Salesforce takes you to Settings → API references — the console where you pick the source Salesforce org and the target docs repo, generate the org-wide data-API spec, sync External Services already registered in Salesforce, and generate any inbound or outbound endpoint on demand.
  • New spec starts a blank OpenAPI file when you want to document something by hand.
Generated specs land under openapi/ in your docs repo — for example openapi/apex-rest/AccountService.yaml — deliberately kept out of the Docs sidebar so the explorer stays the front door.

​
The interactive explorer

The API Reference page lists every spec as a card under Inbound and Outbound, each tagged with its kind — Data API, Apex REST, Named Credential, or External Service — and its operation count. Open one and it renders in an interactive explorer: an endpoints navigation pane alongside request and response examples for each operation. No YAML reading required. For inbound references, Try It is live: requests run against your connected Salesforce org through a server-side proxy signed as your org’s integration user — the browser never holds a token. Anything that could modify data (POST, PUT, PATCH, DELETE) asks you to type the method name to confirm before it sends. Outbound specs render read-only, and an outbound Named Credential gets a live callout tester instead. Each reference page also offers Download (the raw YAML/JSON), History (the spec’s commit history in your git provider), Edit, and Delete:
  • Edit opens the spec’s YAML in the docs editor, in place, with an unsaved-changes guard — no detour through a separate flow.
  • View rendered takes you from the YAML back to the explorer view.
  • Delete removes both the committed file and the reference, after you type delete to confirm.

​
Which references appear

The API reference shows a spec only while the repository holding its YAML file is one of your configured docs repositories (Settings → Docs repositories), and the page follows your active repo:
  • Remove a repo from your docs repositories and its references disappear from the catalog.
  • Add the repo back and the same references reappear — nothing is destroyed either way.

​
Staying current

APIs drift. When the metadata behind a documented endpoint changes — a new parameter on an Apex REST resource, a changed response shape — LivingContext proposes an updated spec as a change request.
Published specs are never rewritten silently. Skeleton specs for brand-new endpoints are committed directly so the catalog is complete from day one, but every change to an existing spec goes through review — and the git history shows exactly what changed and when.

​
Why git as the system of record

Keeping specs as YAML files in the docs repository means:
  • History — every version of every spec, with authorship and timing.
  • Review — spec changes ride the same PR/CR review flow as prose docs.
  • Portability — the specs are standard OpenAPI; any tool in your pipeline can consume them.
Treat the generated spec as a starting point. Because it’s a file in your repo, you can enrich it — descriptions, examples, auth notes — right in the editor, and your additions persist because future updates always arrive as reviewable diffs.