Authentication

Every INFRO API request is authenticated with an API key sent in the Authorization header. Keys are created in the console, start with sk_infro_, and work identically on every endpoint.

Each key carries its own label and optional spend limit, so you can give every service its own key, see what it spends, and cap the damage if one leaks. If you're making your first request, start with the quickstart.

API keys

Keys are sk_infro_ followed by a random string. Copy the full key into your secrets manager when you create it and treat it like a password. If you lose one, revoke it and create a replacement.

Create keys in the console under API keys; each gets a label and an optional spend limit, both covered below. API keys are distinct from BYOK provider keys — credentials for OpenAI, Anthropic, and other providers that you attach so requests route through your own provider accounts. Those are covered in BYOK.

The Authorization header

Pass the key as a bearer token. The header is the only authentication mechanism — there is no query-parameter or cookie alternative.

curl https://api.infro.io/v1/chat/completions \
  -H "Authorization: Bearer $INFRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

A missing, malformed, or revoked key returns 401 with type authentication_error. The examples above are the standard OpenAI clients pointed at INFRO's base URL; see SDKs for other languages and frameworks.

Labels and spend limits

Labels identify keys in the console and in usage analytics. Spend limits are hard ceilings: once a key's usage reaches its limit, its requests return 402 insufficient_credits while your other keys keep working. Both are set at creation and can be changed in the console anytime. Rate limits are also enforced per key — see rate limits.

labelstring

Human-readable name shown in the console, in usage analytics, and in the GET /v1/key response. Use one key per service or environment so spend stays attributable.

limitnumber | null

Hard spend ceiling in USD. Requests return 402 once usage reaches it. null means no per-key cap — the key can spend up to your account balance.

Inspect the current key

GET /v1/key returns the label, spend limit, usage, and remaining budget of whichever key made the request — useful for verifying that a deployment picked up the right key. The full reference (request, response fields, code samples) lives in Rate & spend limits.

Rotating and revoking keys

Revoking a key in the console takes effect immediately — subsequent requests with it return 401. Revoke on any suspected exposure; it can't be undone, but a replacement takes seconds to create.

1. Create a new key in the console with the same label convention and spend limit.
2. Deploy it — update the environment variable or secrets manager entry your service reads.
3. Confirm traffic moved: GET /v1/key from the deployed service should return the new label.
4. Revoke the old key.

Both keys are valid during the overlap, so rotation is zero-downtime.

Security best practices

• Read keys from environment variables or a secrets manager. Never commit them to source control — .env files belong in .gitignore.
• Use one key per service and per environment. Separate keys make usage attributable and let you revoke one integration without touching the rest.
• Set a spend limit on every key. A leaked key with a limit is a bounded problem; a leaked key without one is your whole balance.
• Rotate on any suspicion of exposure. Rotation is zero-downtime, so there's no reason to wait for proof.

401 vs 402

Both statuses mean the request never reached a model, but the fixes differ. Both use the standard error envelope:

{
  "error": {
    "message": "Invalid API key provided.",
    "type": "authentication_error",
    "code": null
  }
}

Neither is retryable — backing off and retrying a 401 or 402 just burns requests. Handle both as configuration errors and alert on them. The full status list and retry guidance are in errors.