Authentication

Mintoken uses a two-key model: one key identifies you on the proxy, the other is your own provider key that we forward upstream. Understanding the split is 90% of knowing how to use the API.

The two keys

curl https://api.mintoken.in/v1/chat/completions \
  -H "Authorization: Bearer mt_live_xxxxx" \
  -H "X-Provider-Key: sk-proj-xxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "model": "gpt-4o-mini", "messages": [...] }'

Creating mintoken API keys

The easiest way to create a key is in the dashboard: click New key, pick a name and intensity, done. You'll see the raw key in a confirmation modal — copy it immediately, because it's not recoverable.

Programmatically

Key management endpoints live under /v1/auth/keys and authenticate with a Supabase access token (the JWT returned from POST /v1/auth/login), not with a mintoken key. See the Key management reference for the full API.

Key rotation

If a key leaks — commits, logs, accidental screen-shares — rotate immediately. Mintoken keys can't be edited in place; rotation means creating a new one and revoking the old:

# Create a new key
curl -X POST https://api.mintoken.in/v1/auth/keys \
  -H "Authorization: Bearer <supabase-jwt>" \
  -H "Content-Type: application/json" \
  -d '{"name": "Production v2", "intensity": "full"}'

# Response (raw_key shown exactly once):
# {
#   "id": "…", "raw_key": "mt_live_abc123…",
#   "key_prefix": "mt_live_abc1", "name": "Production v2", …
# }

# Revoke the old key
curl -X DELETE https://api.mintoken.in/v1/auth/keys/<old-key-id> \
  -H "Authorization: Bearer <supabase-jwt>"

The X-Provider-Key header

Your provider key is sent on every request in the X-Provider-Keyheader. Mintoken uses it to authenticate to the upstream provider and then discards it — we don't log it, store it, or include it in error responses.

Specifics by provider:

Auth errors