Authentication

How Verified API keys are minted, sent, and rejected.

Every inference route expects a product key in the Authorization header:

Authorization: Bearer sk-mifr_<secret>

Mint and revoke keys at Settings while signed in with Google. The full secret is shown once; after that the page lists the prefix, and last-used updates after a verified completion.

Each signed-in user mints keys hashed against their own Google user.id, so Alice’s key only authenticates as Alice. The gateway SHA-256s the Bearer token and asks chat to resolve the hash. Google identity never enters the gateway.

There is no per-key quota yet. Token counts from verified receipts are posted to chat /usage as request and token totals, with no dollar amounts.

Missing or invalid key

HTTP 401 uses the same envelope whether the header is missing, the secret is wrong, or the key was revoked:

{
  "error": {
    "message": "missing or invalid API key (Authorization: Bearer <key>)",
    "type": "invalid_request_error",
    "code": "invalid_api_key",
    "param": null,
    "mifr_action": "fix_key"
  }
}

If chat cannot be reached for lookup, the gateway returns 503 directory_unavailable with mifr_action: wait. That is a directory outage, not a bad key; retry later.

What this page does not cover

Operator keys

MIFR_GATEWAY_KEYS and ~/.mifr/gateway-keys are for ops, listings, and local curl. Completions on those keys have no user.id, and they are not minted from Settings.

CLI login

mifrcli_… in ~/.mifr/account.json links a Mac to an account. It cannot call POST /v1/chat/completions.

Browser CORS

The production website origin is allowlisted. Unknown origins get no Access-Control-Allow-Origin. Completions still need a Bearer token on POST. Preflight OPTIONS is answered with 204 before the key check.

CORS origins default to https://mifr-website-production.up.railway.app (override with MIFR_CORS_ORIGINS). Verdict headers are listed in Access-Control-Expose-Headers.