> ## 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. # Whether a password is needed, and whether requests will be accepted at all > Public, because a client has to be able to ask before it holds a credential. The two fields are two questions, and they come apart in exactly one state: a `closed` mount has no password gate, so `gateEnabled` is false, and a client that reads that as "open" renders itself around a site whose every other route refuses it — with no password box and no way to reach one. `mode` names that state, and `reason` names the environment variable that ends it. Saying so costs nothing: in this state no credential exists, so there is no caller to withhold it from — only the operator looking at a 401 on their own deployment. `mode` and `reason` come from `createOrchestrator()`, whose gate covers every route; the standalone server gates only the agent surface and reports `gateEnabled` alone. Source: `resolveAuth` in `packages/orchestrator-core/src/handler/auth.ts`. ## OpenAPI ````yaml /api-reference/orchestrator.openapi.json get /auth/status 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/status: get: tags: - Auth summary: >- Whether a password is needed, and whether requests will be accepted at all description: >- Public, because a client has to be able to ask before it holds a credential. The two fields are two questions, and they come apart in exactly one state: a `closed` mount has no password gate, so `gateEnabled` is false, and a client that reads that as "open" renders itself around a site whose every other route refuses it — with no password box and no way to reach one. `mode` names that state, and `reason` names the environment variable that ends it. Saying so costs nothing: in this state no credential exists, so there is no caller to withhold it from — only the operator looking at a 401 on their own deployment. `mode` and `reason` come from `createOrchestrator()`, whose gate covers every route; the standalone server gates only the agent surface and reports `gateEnabled` alone. Source: `resolveAuth` in `packages/orchestrator-core/src/handler/auth.ts`. responses: '200': description: >- `{ gateEnabled, mode }`, plus `reason` when `mode` is `closed`. `gateEnabled` is true only when `ACCESS_PASSWORD_HASH` is set: it answers one question — *should the client show a password box?* — and a host that brings its own `auth` hook has no password to collect. `mode` answers the other one — *will my other requests be accepted?* — and is one of `hook` (`config.auth` was supplied, so the host decides per request), `token` (`ACCESS_PASSWORD_HASH` and/or `ORCHESTRATOR_ACCESS_TOKEN` is configured, so the built-in token gate runs), `open-dev` (neither is configured and `NODE_ENV` is not production, so nothing is refused), or `closed` (production with neither configured, so every gated route answers 401). `reason` is the same sentence a closed mount's 401 carries. ````