Keys are created in the console at platform.allternit.com → API Keys → Platform API: create a project (sandbox or live), then Create key, pick its scopes and, optionally, one account. The console calls
POST /api/v1/platform/projects/{id}/keys with your signed-in session. Creating a key asks you to accept the Developer Terms and Acceptable Use Policy; a live key can’t be created without it (400 terms_not_accepted), and the time and terms version are recorded on the key. The full key is shown once; only its hash is stored. A key can never create another key. Revoke a key with DELETE /api/v1/platform/projects/{id}/keys/{key_id}. Only the project owner, or an admin of the project’s organization, can manage its keys.
The console
The console at platform.allternit.com → Platform API has pages for Projects, Agents (with model keys), Conversations, Computers, Usage and Webhooks. Those pages call the same/v1 endpoints described here, with your signed-in Clerk session instead of a key plus the header X-Allternit-Project: proj_…. The API then acts on that project as its owner: every scope, no account binding, and its requests are keyed as console:<user id> for rate limits, idempotency and usage. A project you can’t manage, or an archived one, answers 404 project_not_found. A project key in Authorization always wins over the header. This is for the console; servers should use project keys.
Older alt_ keys (account keys, not project keys) keep working for the routes they always reached; they don’t authenticate on the Platform API.
Scopes
A key carries one or more scopes. A route that needs a scope the key lacks answers403 permission_error.
Accounts can be managed with any resource scope (
agents, voice, messaging, numbers, channels, twin or webhooks).
Account-bound keys
Create a key with anaccount_id to hand it to one customer’s backend. That key sees only its own account: it can read and rename that account, it can’t create or delete accounts, and every list it reads is filtered to the account.