> ## Documentation Index > Fetch the complete documentation index at: https://docs.deploybaseline.com/llms.txt > Use this file to discover all available pages before exploring further. # API reference > Browse every route the emulators you started serve, and send requests to them, at /docs on your machine. 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. ```bash theme={null} npx @deploybaseline/cli start --service stripe,github ``` ```text theme={null} API reference: http://localhost:3999/docs (every service above) ``` Open the link to switch between services, search operations, read response schemas, and send requests. Pick one service with `/docs/`, 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](https://docs.deploybaseline.com/configuration.md#fault-injection) at `/_baseline/control`, which every service port also answers. | Flag | Effect | | - | - | | `--console-port ` | Serve the console on another port. | | `--no-console` | Do not open the console port. Services and the control API on their ports are unchanged. | 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: | Path | What it returns | | - | - | | `GET /docs/services.json` | Every service this process started, its URL, and the paths of its reference and document. Custom services are listed without a document. | | `GET /docs//openapi.json` | The service's OpenAPI 3.1 document, with `servers` set to its URL. | ```bash theme={null} curl -s http://localhost:3999/docs/stripe/openapi.json | jq '.paths | keys | length' ``` The page itself uses [Scalar](https://github.com/scalar/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: | Source | What it contributes | | - | - | | The routes each plugin registers | The list of operations. A route exists in the reference if and only if the emulator serves it. | | The provider guide (`docs/.mdx`) | Titles, descriptions, and the grouping of operations, taken from the route lines and headings of the guide. | | The vendored vendor spec (`packages/@deploybaseline//spec/openapi.json`) | Response schemas, pinned to an upstream commit with its license. | | The coverage matrix (`src/__tests__/coverage.ts`) | `x-baseline-status`: `supported` or `partial`, with notes for partial routes. | Each document is written to `packages/@deploybaseline//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: ```mdx theme={null} - `POST /v1/customers` - Create customer: name, email, metadata ``` 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](https://github.com/deploybaseline/baseline-cli/blob/main/CONFORMANCE.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.