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
| 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