authentication

API keys

Every request carries a bearer token in the Authorization header. Keys begin with mg-live-.

Authorization: Bearer mg-live-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The secret is shown once

At creation, and never again. We store a SHA-256 hash of the key, not the key, so there is no “show me my key” button and no support request that can recover it, including for us. If you lose one, revoke it and create another.

A key is 32 bytes of cryptographically random data, so there is nothing for a dictionary attack to work with. Hashing with SHA-256 rather than a deliberately slow function keeps key verification off the critical path of every inference request.

Restricting a key

Two optional controls, set when you create the key or later:

• Allowed models. An empty list means every model your account can reach. A non-empty list is an allowlist, a request for anything else returns 403 model_not_permitted.
• Spend limit. A lifetime cap in USD for that key. Once reached the key returns 402 key_spend_limit_reached and stops working, while your other keys carry on. Useful for a key you hand to a script, a contractor, or an integration you are unsure about.

Both are checked before any model runs, so a restricted key cannot spend money it is not allowed to spend.

Revoking

Revocation is immediate and permanent, a revoked key cannot be un-revoked. In-flight requests finish; the next one gets 401 invalid_api_key.

Keeping keys safe

• Keys belong on a server. Anything in a browser bundle or a mobile app is public, whatever the build tooling implies.
• Use a separate key per integration. Revoking one then does not take down the others, and the usage dashboard shows which integration is spending what.
• Put a spend limit on anything you do not fully control. It is the only control that bounds the damage rather than just recording it.