Skip to main content

API-key lifecycle

API keys give machine-to-machine access to Advania ALT for CI pipelines, SDK integrations, and automated scripts. They carry the same identity as their creator, minus the role — a key can never do what its owner can as an Admin.

Properties​

  • Prefix + 43 characters — the plaintext key is shown only at creation. Store it immediately.
  • Scopes — capability-based; a request outside the key's scope returns 403 Forbidden
  • TTL — every key has an expiry. Default 90 days, maximum 365 days.

See API keys in Getting Started for the scope list and creation walkthrough.

Creating a key​

Keys are created through the console (recommended) or the API. API creation requires a signed-in user session, not an API key.

curl -sS -X POST https://api.alt.advania.ai/v1/api-keys \
  -H "Authorization: Bearer $ALT_JWT" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ci-pipeline",
    "scopes": ["chat:completions", "models:read"],
    "expires_at": "2026-10-02T00:00:00Z"
  }'

The full request/response shape is in the interactive OpenAPI.

Rotating a key​

There is no in-place rotation. The pattern is create-new → deploy → verify → revoke-old:

  1. Create a new key with the same scopes and a fresh TTL
  2. Deploy it to your workload
  3. Verify it works (a /v1/me call is fine)
  4. Revoke the old key

Recommended rotation cadence for production keys: every 30-60 days, or whenever a team member with access leaves.

Revoking a key​

curl -sS -X POST https://api.alt.advania.ai/v1/api-keys/{id}/revoke \
  -H "Authorization: Bearer $ALT_JWT"

Revocation is immediate — the key is rejected on the next request. It is also idempotent — revoking an already-revoked key is safe.

Admins can revoke any key; Developers can revoke only their own.

Owner deactivation​

When the user who owns a key is removed from the account, all of that user's keys are disabled at the same moment. They aren't deleted — a rehired user reactivates their keys automatically — but they can't authenticate while the owner is inactive.

For shared CI accounts, use a service-account-style user (not a departing employee) as the key owner if the key needs to outlive any individual.

Why API keys can never be Admins​

API keys carry scopes, not roles. Even an Admin's key cannot call user-management or account-configuration endpoints — those require a signed-in user session. Automation cannot escalate to Admin, by design.