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

# Manage API keys

> Create scoped Brightnode API keys for inference and deployment workflows.

Brightnode API keys are used for programmatic access to hosted inference and deployment workflows. Keys are created in the console, start with the `bn-` prefix, and should be treated like passwords.

## Create an API key

Follow these steps to create a new Brightnode API key:

1. In the Brightnode console, open the [API Keys page](https://console.brightnode.cloud/api-keys).
2. Select **Create Key**.
3. Give the key a descriptive name such as `production-router` or `staging-deployments`.
4. Select one or both available scopes:
   * `Inference` for Router and model API calls.
   * `Deployments` for deployment-oriented workflows.
5. Optionally set an expiry date.
6. Select **Create Key**, then copy the secret value immediately.

<Warning>
  Brightnode only shows the full API key once. Store it in your secret manager or environment configuration before closing the dialog.
</Warning>

## Scopes

Use the smallest scope that fits your integration:

* `Inference`: Call the hosted inference API, including `/v1/models`, `/v1/chat/completions`, and `/v1/embeddings`.
* `Deployments`: Manage deployment workflows intended for model deployment use cases.

If you only need hosted inference, create an inference-only key and keep deployment access separate.

## Use your API key

Use the key as a bearer token:

```bash theme={"system"}
curl https://api.brightnode.cloud/v1/models \
  -H "Authorization: Bearer $BRIGHTNODE_API_KEY"
```

You can also use the same key with OpenAI SDKs by setting `base_url` to `https://api.brightnode.cloud/v1`. For end-to-end examples, see [Router](/router/overview) and [Models](/models/overview).

## Rotate or revoke keys

Review your keys regularly and revoke unused credentials from the [API Keys page](https://console.brightnode.cloud/api-keys). For production systems, prefer separate keys per environment or service so that rotation and incident response stay simple.
