Authentication and API keys
Every request to the API carries an authorization header with a token:
Authorization: Bearer <token>
That token identifies who is calling and which company (tenant) it acts in. Without it, the API responds 401.
Two kinds of token
| Kind | How you get it | Lifetime | Typical use |
|---|---|---|---|
| Session JWT | On logging in to the web | Short, expires | The web UI itself |
| API key | Minted from a logged-in session | Long-lived | Agents, scripts, integrations |
Both are sent the same way, as Bearer <token>. The difference is lifetime and purpose: the JWT is ephemeral and serves the web; the API key is durable and serves agents.
API keys (agl_)
API keys carry the agl_ prefix and are minted from an already logged-in session, at:
POST /api/v1/auth/api-keys
Store it in a secrets manager or environment variable; it is shown only once. By default a key has scope *, meaning it can operate on your company's whole accounting, just like you do from the web.
An
agl_key grants full access to your accounting. Treat it like a password: don't publish it, don't put it in commits or logs. If it leaks, revoke it and mint a new one.
Verify a token
To check that a token is valid and see the active company, call /api/v1/tenants/me:
curl https://api.aikount.com/api/v1/tenants/me \
-H "Authorization: Bearer agl_your_key_here"
A 200 response with the company details confirms the token works.
Important:
/auth/meis session-only (login) and rejects API keys. With anagl_key, always use/api/v1/tenants/meto verify the token and learn the active tenant.
401 vs 403
401 Unauthorized— the token is missing, invalid or revoked. Check theAuthorizationheader and that the key is still active.403 Forbidden— the token is valid but lacks the scope for that operation. With a scope*key you shouldn't see this except on restricted operations.
Errors arrive as an HTTP status plus a {"detail": "..."} body (see API conventions).
Next step
With a key ready, connect your agent in Connect an agent or over MCP.