Authentication
Accounts, API keys, and sign-in
The API, CLI, and MCP server all require an aVenture account; free and paid plans both work. How you sign in depends on where you work:
Create an API Key
- Sign in to aVenture.
- Open API Keys settings.
- Choose Add new key.
Store the key in your secret manager and load it into the AUTH_TOKEN
environment variable at runtime. The same page lists and revokes your keys.
Send it on every request:
A 200 confirms the key works and lists what it can reach.
Sign In From the CLI
The command opens your browser for OAuth sign-in. For SSH, containers, or another device, use:
When the issuer advertises OAuth device authorization, --no-browser uses
that flow: open the returned URL on your device, approve the displayed code,
and let the CLI finish verifying and storing its OAuth access. If device
authorization is unavailable, follow the reported error rather than assuming
a loopback callback will complete in a headless session.
aventure auth login --key --no-browser is a separate API-key approval
fallback. It is not required for OAuth device approval.
Developer Access settings lists past
CLI sign-ins and revokes them. In CI, set AUTH_TOKEN to an API key instead.
Connect an MCP Client
The MCP quickstart has setup instructions and prompts for your AI app, plus the server URL and automatic OAuth registration settings. Your client signs you in through the browser when it connects.
Keep Credentials Safe
Anyone holding an API key or token has the access it grants, and their calls use your allowances. Keep credentials server-side, load them from a secret manager, and never ship one in browser code or commit one to a repository.
When Authentication Fails
A missing, expired, or unrecognized credential returns 401, and its detail
says how to sign in:
A valid credential that lacks permission for an operation returns 403; signing
in again does not change it. Both use the standard error body.