> ## Documentation Index
> Fetch the complete documentation index at: https://dench.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Authenticate to the Dench API

> Send a bearer token on every Dench API request using a workspace API key for services or an agent session token from dench signin.

Send a bearer token on every request:

```http theme={null}
Authorization: Bearer <token>
```

<Tabs>
  <Tab title="API key">
    Workspace-scoped key from settings, ideal for CI and services. The same key
    is exposed to sandboxes as `DENCH_API_KEY`.

    ```bash theme={null}
    curl -sS https://www.dench.com/api/v1/status \
      -H "Authorization: Bearer $DENCH_API_KEY"
    ```
  </Tab>

  <Tab title="Agent session">
    A token from `dench signin` (starts with `dch_agent_`). Gateway-backed
    routes exchange it for the workspace gateway key automatically.

    ```bash theme={null}
    curl -sS https://www.dench.com/api/v1/context \
      -H "Authorization: Bearer $DENCH_AGENT_SESSION"
    ```
  </Tab>
</Tabs>

<Info>
  Authentication is wired into the **API Reference** playground, enter your token
  once and every "Try it" request uses it.
</Info>

## Run attribution

When an API-key caller acts from inside a running agent turn, include the run id
so Dench attributes the action to the right user:

```http theme={null}
x-dench-run-id: <run_id>
```

<Note>
  Local session commands (`dench sessions`, `dench use`, `dench logout`,
  `dench backend`, `dench fs`) stay on the CLI, they change the caller's machine
  and have no server endpoint.
</Note>