Skip to main content
The API reference lives in the CLI, not on this site. Each running Baseline process serves a reference for the services it started, at /docs on its console port, with every request in the playground going to the emulator on your machine.
Open the link to switch between services, search operations, read response schemas, and send requests. Pick one service with /docs/<service>, for example http://localhost:3999/docs/stripe.

The console port

The console listens one below the base port: 3999 with the default base of 4000, or 4999 with --port 5000. Next to /docs it serves the control API and inspector at /_baseline/control, which every service port also answers. A service configured on the console port is an error at start. When another program already holds the port, Baseline prints a warning and starts the services without the console.

For tools and agents

The OpenAPI documents need no network, and their servers entry is where that service listens in this process:
The page itself uses Scalar. Baseline serves an installed @scalar/api-reference (next to your project or the CLI), and otherwise loads a pinned release from jsDelivr, so a browser with no internet access needs npm install @scalar/api-reference in the project.

How the reference is built

Nothing in it is written by hand. pnpm api-reference (or make api-reference) builds a document per provider from four sources in the repository: Each document is written to packages/@deploybaseline/<provider>/api-reference.json, and the CLI ships them all. Every operation carries x-baseline-route, the route pattern exactly as registered, and x-vendor-operation when it matches an operation in the vendor’s spec. A route line in a provider guide gives the operation its title:
The title is the text before the first colon, comma, or parenthesis. Text that does not read as a title (longer than 48 characters, quoting code, or describing parameters) is left out, and the operation is named from its path instead.

How it stays in sync

1

Code and reference

CI runs pnpm api-reference --check. Adding, removing, or renaming a route without regenerating the reference fails the build.
2

Docs and code

The same check fails when a provider guide mentions a route the emulator does not register, so a removed or misspelled route cannot linger in the docs.
3

Emulator and vendor

During tests, every JSON response is validated against the vendored vendor schema for its operation (the spec gate). Mismatches fail the provider’s test run unless they are allow-listed with a reason.
4

Vendor and upstream

A weekly workflow fetches each vendor’s latest spec, and opens a pull request with the changed shapes and the failing responses when upstream changes.
Where a vendor publishes no OpenAPI document under a license Baseline can vendor, responses are left untyped and the provider guide describes them. See CONFORMANCE.md.