---
title: Authentication | Boltz API Docs
description: Pass your API key and understand key scoping rules.
---

## Authenticate

Read `BOLTZ_API_KEY` from your environment and pass it to your client. For the CLI, sign in with `boltz-api auth login`. For coding agents, device-code login is usually the most reliable because it does not require the agent sandbox to open a browser.

- [Scientist Python](#tab-panel-10)
- [Scientist CLI](#tab-panel-11)
- [Platform Developer Python](#tab-panel-12)
- [Platform Developer Typescript](#tab-panel-13)
- [Agent CLI](#tab-panel-14)

```
import os
from boltz_api import Boltz


client = Boltz(api_key=os.environ["BOLTZ_API_KEY"])
```

Terminal window

```
boltz-api auth login
```

```
import os
from boltz_api import Boltz


client = Boltz(api_key=os.environ["BOLTZ_API_KEY"])
```

```
import Boltz from "boltz-api";


const apiKey = process.env["BOLTZ_API_KEY"];


const client = new Boltz({ apiKey });
```

Terminal window

```
boltz-api auth login --device-code
boltz-api auth status
```

Or provide an API key where the agent runtime can read it:

Terminal window

```
export BOLTZ_COMPUTE_API_KEY="your-api-key"
```

## Choose the right key type

There are two types of API keys. Which one you use depends on what you need to do.

### If you need to manage workspaces or query usage

Use an **admin key**. Admin keys are scoped to the organization level and can:

- Create, list, and update workspaces
- Manage API keys for any workspace
- Run jobs across the organization
- Query usage data across the organization

For job endpoints that accept `workspace_id`, an admin key can target any non-archived workspace in the organization. If `workspace_id` is omitted, the request uses the default workspace.

### If you only need to run jobs

Use a **workspace key**. Workspace keys are scoped to a single workspace and can only run jobs (predictions, design runs, library screens) on that workspace. If `workspace_id` is provided, it must match the workspace assigned to the key.

## Key scoping summary

| Capability        | Admin key                                                                                           | Workspace key         |
| ----------------- | --------------------------------------------------------------------------------------------------- | --------------------- |
| Manage workspaces | Yes                                                                                                 | No                    |
| Manage API keys   | Yes                                                                                                 | No                    |
| Run jobs          | Any workspace in the organization; defaults to the default workspace when `workspace_id` is omitted | Scoped workspace only |
| Query usage       | Yes                                                                                                 | No                    |

## Key prefixes

Each key type has a distinct prefix so you can identify it at a glance:

| Prefix              | Key type             |
| ------------------- | -------------------- |
| `sk_bc_admin_live_` | Admin key (live)     |
| `sk_bc_admin_test_` | Admin key (test)     |
| `sk_bc_ws_live_`    | Workspace key (live) |
| `sk_bc_ws_test_`    | Workspace key (test) |

The full key is shown only once — at creation time. After that, use the `key_prefix` field on the API key resource to identify which key you’re looking at.

See [Organizations & Workspaces](/docs/guides/organizations-and-workspaces/index.md) for more on how workspaces and keys relate.