# Authenticate requests (/get-started/authentication)



OpenMetal has two credential classes. They are not interchangeable.

## Project API keys [#project-api-keys]

Use a project key for sandbox lifecycle, operations, processes, files, and leased HTTP endpoints.

```http
Authorization: Bearer metal_sk_your_key
X-Metal-Project-ID: prj_your_project
```

The operation read and event routes require the exact project key that created the sandbox, but they do not require `X-Metal-Project-ID`.

Project keys are returned once when created. Store them in a secret manager or the CLI credential store.

## User access tokens [#user-access-tokens]

Use an OpenMetal user access token to manage organizations, members, projects, API keys, provider
credentials, billing, usage, webhooks, and durable project events.

```http
Authorization: Bearer <openmetal-user-access-token>
```

The dashboard and CLI create and refresh this session after you sign in. Advanced SDK integrations
can provide a token callback:

```ts
const controlPlane = new MetalClient({
  baseUrl: process.env.OPENMETAL_API_URL!,
  accessToken: () => process.env.OPENMETAL_ACCESS_TOKEN,
});
```

<Callout type="error" title="Fail closed">
  Do not use a user access token for project key routes or a project key for user administration
  routes. OpenMetal rejects credentials with the wrong scope.
</Callout>

## Security checklist [#security-checklist]

* Keep credentials out of repositories and browser bundles.
* Never place a token inside sandbox metadata, environment configuration, or process arguments.
* Rotate project keys and give each workload its own key.
* Treat one time key output as sensitive terminal output.

See [the API reference](/api-reference) for route specific security requirements.