Skip to main content

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.

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. 
Authorization: Bearer YOUR_PROVISIONING_KEY

​
Create A Key

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"))
The create response includes the plaintext key once. Store it immediately.
API keys are only shown in plaintext once at creation time. Store them securely right away.

​
Other Operations

OperationEndpointUse it for
List keysGET /v1/account/keysinventory and auditing
Get one keyGET /v1/account/keys/{key_id}inspect metadata for one key
Update a keyPATCH /v1/account/keys/{key_id}rename, disable, or change limits
Delete a keyDELETE /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