Authentication

One Bearer key for every /v1 call. Keys are issued in the cabinet and shown exactly once.

Every /v1 call authenticates with an Authorization header carrying your key. There is no other scheme — no query parameters, no cookies.

POST https://mintform.app/v1/* every generation request authenticates the same way
curl https://mintform.app/v1/chat/completions \
  -H "Authorization: Bearer $MINTFORM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5-mini","messages":[{"role":"user","content":"ping"}]}'

Key lifecycle

Keys are created on the Keys page in the cabinet. The mf_live_… secret is returned once, at issue time; once the dialog closes it cannot be read again, only rotated.

  • Issue: the key is active immediately and inherits the limits of your plan.
  • Rotate: the old secret stops working the moment the new one appears.
  • Revoke: the key is disabled immediately and permanently; calls with it get 401.

Storing the key

Keep the key in environment variables or a server-side secret manager. A key shipped in client code — browser, mobile app, public repository — should be treated as compromised and rotated at once.

# .env — never commit the raw key
MINTFORM_API_KEY=mf_live_…

Authentication failures

A missing, revoked or malformed key is refused with 401 before routing happens, so the call costs you no quota.

HTTPMessageWhat to do
401missing bearer tokenNo Authorization header, or it is not in Bearer form.
401invalid or disabled keyThe key is unknown or revoked — issue a new one in the cabinet.

Multiple keys

Issue one key per environment or service. You can then revoke a single key without touching the others, and the cabinet logs and stats show which one spent the quota.