Skip to main content
POST
Establish the signed-in user's Audivo session

Authorizations

Authorization
string
header
required

A Cognito access token, issued through the dashboard's own sign-up and sign-in pages (a backend-for-frontend; there is no Cognito Hosted UI) and sent as Authorization: Bearer <jwt>. Dashboard operations require this scheme and cannot be called with an API key, with no exception. GET /v1/usage and GET /v1/limits offered both schemes from 0.8.0; 0.8.1 withdrew that, because the control-plane API serves them alone and its authorizer has no API-key branch. An account_id supplied by the client is ignored; all reads/writes are scoped server-side to the authenticated account.

Response

The account this session acts for.

What one session carries. Deliberately no balance and no credit figure: a number frozen into a session outlives itself, and GET /v1/usage reads the live one.

account_id
string
required

The calling account's opaque identifier. Self-serve accounts derive it from the Cognito subject, so it is stable for the life of the account and identical however the account was created; operator-provisioned accounts predate that and carry arbitrary names within the same shape. Callers must not parse it or infer anything from its body.

Maximum string length: 155
Pattern: ^acct_[A-Za-z0-9_-]{1,150}$
tier
enum<string>
required
Available options:
free,
hobby,
startup,
growth,
scale
status
enum<string>
required

The account's own state. active is the only one that may spend: suspended is a billing or abuse hold, and deleting/deleted are a deletion in progress or complete. Reads stay open in every state until the account's API keys are revoked, which is when access actually ends — so a non-active status is a reason to show the customer their billing page, not a reason to sign them out.

Available options:
active,
suspended,
deleting,
deleted