Authentication

Bearer tokens, exactly as OpenAI does it.

Authorization: Bearer isk-v1-...

Keys are prefixed isk-v1- followed by 64 hex characters — 256 bits of entropy. The prefix makes them recognisable in a secret scanner, and the version segment means the format can change without ambiguity.

How keys are stored

We store an HMAC-SHA256 digest, never the key. The plaintext exists once, in the response that creates it.

Keying the hash rather than using a bare digest means an attacker holding a copy of our database still cannot verify guesses offline — they would need the application secret too, and that lives in the environment rather than in the database. The two have to be breached separately.

We cannot recover a lost key. There is no support process that retrieves one, because there is nothing to retrieve. Revoke it and create another.

Restricting a key

Each key can be narrowed independently of the workspace it belongs to:

Spend limit. A lifetime cap in USD. Once reached, the key returns 402 while the rest of the workspace keeps working. Useful for a contractor, a demo, or a CI job you’d rather not have run away.
Model allowlist. Restrict a key to specific models. Anything else returns 403.
Rate limit. A lower per-minute ceiling than the workspace default. A key can tighten the workspace limit but never raise it.
IP allowlist. Exact addresses or CIDR ranges.

Revocation

Revoking takes effect within about a second: we delete the key from the gateway’s cache immediately rather than waiting for the entry to expire. A revoked key that keeps working for a minute is not acceptable when you’re rotating a leaked credential.

Checking a key

curl https://api.infersia.com/v1/key \
  -H "Authorization: Bearer $INFERSIA_API_KEY"

Returns the key’s label, its limits, its lifetime spend and the workspace balance — without spending anything. Useful as a health check at application startup.