TEASEDocs
ProductsAccount Platform

API — Account API keys

A creator mints their own Bearer API keys to drive the platform from their own Claude / MCP client — create, list, and revoke, scoped to that creator's tenant only.

Mounted at /api/me/api-keys (app/main.py:156, router in app/api/ me_api_keys.py). Auth is the panel session cookie (require_user) — this is a self-serve creator flow, not the workspace owner's separate admin key CRUD at /api/admin/api-keys. Every row is stamped and filtered by the caller's own owner_id — a creator can never see, mint over, or revoke another tenant's key.

The token is shown exactly once

POST returns the full al_live_<prefix>_<secret> token in the response body. It is never returned or logged again afterward — only prefix and last4-style metadata are ever exposed again. Store it immediately.

POST /api/me/api-keys

Mints a new key. 201 Created.

Body: name (1–128 chars), scopes (optional list — default ["read", "write"]; valid values are read, write, automation, fansly_write, fansly_journal), expires_in_days (optional, 1–3650; omitted or null = never expires), code (optional TOTP/backup code).

  • 400 invalid_scope if scopes contains anything outside the valid set.
  • 401 twofa_required if the account has 2FA enabled and code is missing or wrong — minting a Bearer credential is treated as a credential-issuing action and requires a fresh second factor, the same as issuing an API key is gated in Security.
  • Response: { id, name, prefix, token, scopes, created_at, expires_at }token only appears in this one response.

GET /api/me/api-keys

Lists the caller's own keys, newest first. Never returns token, the hash, or the salt.

Response: { "items": [{ id, name, prefix, scopes, last_used_at, created_at, revoked, expires_at }] }.

DELETE /api/me/api-keys/{key_id}

Soft-revokes one of the caller's own keys. 204 No Content on success; 404 api_key_not_found if the id doesn't exist or belongs to someone else — the same response either way, so a probe can't distinguish "not yours" from "doesn't exist".

Revocation is immediate

Revoking clears the key's cached Bearer-verification entry right away rather than waiting for the cache to expire on its own — a revoked key stops working on the very next request, not after some TTL.

What's next

For how a key is checked on each request and what a 2FA-enabled account must prove to manage it, see Security.

On this page