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

# API Keys

> Create, list, update, and delete API keys with provisioning-key authentication.

Use the account API-key endpoints when you need to manage inference keys programmatically.

This is the right workflow when you want separate keys for production, staging, development, CI, or customer-specific workloads.

## Authentication reminder

These endpoints require your provisioning key, not a standard inference key.

```bash theme={null}
Authorization: Bearer YOUR_PROVISIONING_KEY
```

## Create A Key

<CodeGroup>
  ```python Python theme={null}
  import requests

  response = requests.post(
      "https://api.naga.ac/v1/account/keys",
      headers={
          "Authorization": "Bearer YOUR_PROVISIONING_KEY",
          "Content-Type": "application/json",
      },
      json={
          "name": "CI worker",
          "credit_limit": 25.0,
      },
  )
  response.raise_for_status()

  key_data = response.json()
  print(key_data["id"])
  print(key_data.get("key"))
  ```

  ```javascript Node.js theme={null}
  const response = await fetch('https://api.naga.ac/v1/account/keys', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer YOUR_PROVISIONING_KEY',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: 'CI worker',
      credit_limit: 25.0,
    }),
  });

  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }

  const keyData = await response.json();
  console.log(keyData.id);
  console.log(keyData.key);
  ```

  ```bash cURL theme={null}
  curl https://api.naga.ac/v1/account/keys \
    -H "Authorization: Bearer YOUR_PROVISIONING_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "name": "CI worker",
      "credit_limit": 25.0
    }'
  ```
</CodeGroup>

The create response includes the plaintext key once. Store it immediately.

<Warning>
  API keys are only shown in plaintext once at creation time. Store them
  securely right away.
</Warning>

## Other Operations

| Operation    | Endpoint                           | Use it for                        |
| ------------ | ---------------------------------- | --------------------------------- |
| List keys    | `GET /v1/account/keys`             | inventory and auditing            |
| Get one key  | `GET /v1/account/keys/{key_id}`    | inspect metadata for one key      |
| Update a key | `PATCH /v1/account/keys/{key_id}`  | rename, disable, or change limits |
| Delete a key | `DELETE /v1/account/keys/{key_id}` | revoke a key permanently          |

## Practical Patterns

### Environment Separation

Create separate keys for:

* production
* staging
* development
* testing or CI

This makes usage attribution and incident response simpler.

### Budget Control

Use `credit_limit` to cap how much a key can spend. This is useful for:

* sandbox environments
* short-lived experiments
* customer-isolated workloads

### Key Rotation And Revocation

* disable or update keys when rotating credentials
* delete keys that are no longer needed
* remember that deleting a key is irreversible for any client currently using it

## Common mistakes

* using a normal API key instead of a provisioning key
* forgetting to store the plaintext key at creation time
* sharing one key across unrelated environments when you need clear attribution

## Related Reference Pages

* [List API keys](/api-reference/endpoints/account/api-keys/list)
* [Create an API key](/api-reference/endpoints/account/api-keys/create)
* [Update an API key](/api-reference/endpoints/account/api-keys/update)
* [Delete an API key](/api-reference/endpoints/account/api-keys/delete)