API keys

API keys are the credential of choice for production traffic and any process you don’t want to log into 10ex with a human account. They’re long-lived, hashed in the database, and prefixed with tnx_ so you can spot them in code review.

In v1 you mint keys from the Starlette admin panel. The same operations are exposed as MCP tools so an agent can mint a key on your behalf during onboarding.

How to mint, list, and revoke a key

From the admin shell or any MCP-connected agent:

mint_api_key({ name: "ci-deploy" })   →  { prefix: "abc12345", secret: "tnx_abc12345_..." }
list_api_keys()                       →  [{ prefix, name, last_used_at, scopes, created_at }]
revoke_api_key({ prefix: "abc12345" })

The full secret is shown only once at creation. Copy it into your secrets manager immediately. If you lose it, mint a new one and revoke the old one. There’s no recovery path.

A typical CI mint:

curl -X POST https://api.10ex.ai/api/v1/admin/api-keys \
  -H "Authorization: Bearer $ADMIN_JWT" \
  -H "Content-Type: application/json" \
  -d '{"name": "ci-deploy"}'

Sample response:

{
  "prefix": "abc12345",
  "secret": "tnx_abc12345_kY3pZ1qX...",
  "scopes": ["*"],
  "created_at": "2026-05-08T14:22:01Z"
}

Storage rules

• Never commit tnx_... to git. Pre-commit hooks like gitleaks will catch the prefix.
• Use .env.local (gitignored) for local dev.
• Use your platform’s secrets manager (AWS Secrets Manager, Vercel, Doppler) for deployments.
• Rotate at least quarterly and on every team turnover.

Common mistakes

• Reusing one key across staging and production. If staging leaks, prod is compromised. Mint one per environment.
• Storing the secret in a CI variable that’s logged in build output. Mask it explicitly.
• Forgetting to revoke a key when an engineer leaves. Add it to your offboarding checklist.

Related

• Authentication: when to pick a key vs a JWT
• Rate limits: per-key throttling