> ## Documentation Index > Fetch the complete documentation index at: https://docs.avocadostudio.dev/llms.txt > Use this file to discover all available pages before exploring further. # Exchange the access password for a bearer token > This route is the password exchange and nothing else. Post `{ password }`; the editor stores the token that comes back and attaches it as `x-access-token` (and as `?accessToken=` on `EventSource`, which cannot send headers). Where the deployment is open by choice, or gated by something other than a password, a token still comes back so the client's code path is identical either way — it is simply not what any gate is checking. A `closed` mount is the exception, and it answers 503. Production with no credential configured has no password to exchange and refuses every route behind this one, so a token minted here would open nothing: the operator would hold a credential and a 401 on every request, with no way to connect the two. It returns the sentence naming the variable that would open the mount instead. ## OpenAPI ````yaml /api-reference/orchestrator.openapi.json post /auth/verify openapi: 3.0.3 info: title: Avocado Studio Orchestrator API description: >- HTTP API exposed by the orchestrator. The brain that runs editor sessions, calls the LLMs, and serves draft state to integrated sites. The route list is the one the standalone Fastify server registers (`apps/orchestrator/src`); the handlers behind most of them live in `packages/orchestrator-core/src/http`, so library mode — `createOrchestrator()` from `@avocadostudio-ai/site-sdk` — serves the same shapes from the same code. Where the two differ, the route says so. **Note**: most routes carry no Fastify response schema, so responses are described in prose rather than typed here. Request shapes are taken from the handler source. See [the API Reference index](/api-reference) for context. **Auth**: in the standalone server only the agent surface enforces the access gate — `/chat` and `/ops` remain open. `createOrchestrator()` gates every route instead. Under that gate `GET /auth/status`, `POST /auth/verify`, `GET /health` and `GET /generated-images/*` are public — the first two are how a caller obtains a credential, a probe that needs one is not a probe, and an image tag on the rendered page cannot send a header — while every other route wants the token as `x-access-token`, `Authorization: Bearer`, or `?accessToken=` on `EventSource`. A refusal is `401` with `{"error":"unauthorized"}`. On a `closed` mount — `NODE_ENV=production` with no credential configured and no `auth` hook — that body also carries `reason`, the sentence naming the variable that would open it; `error` keeps its exact value either way, because that is the field the editor matches on to re-prompt. version: 0.11.1 servers: - url: http://localhost:4200 description: Local development orchestrator (default port) security: [] tags: - name: Sites description: Site registration and listing - name: Chat description: AI chat / planning endpoints - name: Sites Agent description: Site onboarding agent (migrate / integrate / create) - name: Draft description: Draft content read endpoints called by integrated sites - name: Publish description: Publishing and content snapshot endpoints - name: History description: Undo / redo / version log - name: Auth description: Optional access password gate - name: Media description: Image upload and generation - name: Health description: Service health and readiness - name: Operations description: Applying typed content operations directly - name: Checks description: Site-health check runs and findings - name: Restore description: Publish snapshots and rolling a draft back to one - name: Sessions description: Session introspection and admin - name: Preview description: Preview utilities - name: Telemetry description: Chat pipeline traces and feedback - name: Agent description: Open-ended agent loops — gated, and off in production by default - name: Jira description: Jira as a second input channel paths: /auth/verify: post: tags: - Auth summary: Exchange the access password for a bearer token description: >- This route is the password exchange and nothing else. Post `{ password }`; the editor stores the token that comes back and attaches it as `x-access-token` (and as `?accessToken=` on `EventSource`, which cannot send headers). Where the deployment is open by choice, or gated by something other than a password, a token still comes back so the client's code path is identical either way — it is simply not what any gate is checking. A `closed` mount is the exception, and it answers 503. Production with no credential configured has no password to exchange and refuses every route behind this one, so a token minted here would open nothing: the operator would hold a credential and a 401 on every request, with no way to connect the two. It returns the sentence naming the variable that would open the mount instead. requestBody: required: false content: application/json: schema: type: object properties: password: type: string responses: '200': description: '`{ ok: true, accessToken }`.' '400': description: '`password` is required when the gate is enabled.' '401': description: Incorrect password. '503': description: >- `{ ok: false, error: "unavailable", reason }` — the mount resolved to mode `closed`, so there is no password to exchange. `reason` is the identical string `GET /auth/status` returns, naming `ACCESS_PASSWORD_HASH`, `ORCHESTRATOR_ACCESS_TOKEN` and `config.auth`. Only `createOrchestrator()` can be `closed`. ````