Skip to main content
A z_sk_ key grants full organization-scoped access: no per-key scopes, no read-only type. Any valid key reaches the whole catalog and spends against the balance. Treat it as a password with full account access. The server keeps only a one-way hash. You see the raw key once, at creation. Lost it? Rotate.

​
Store in Secrets

  • Load from the environment (NITO_API_KEY) or a secrets manager. Never commit it.
  • Never ship a key in browser or mobile code. Route model calls through your backend.
  • Never log the Authorization header. See Privacy-Safe Logging.

​
Isolate and Cap

  • One key per workload. Revoke one without taking down the rest, and see from usage which workload it belongs to.
  • A spend cap on every key. daily and monthly caps block the key until the UTC window resets; an overall cap expires it. A leaked key becomes a bounded liability. See Cost Control.

​
Rotate

There is no edit operation: create a new key in the developer console, deploy it, revoke the old one. Rotate on a schedule and immediately on suspicion.

​
Who Can Manage Keys

Only owner and admin roles create, list, or revoke keys. Keep that set small and review it when people join or leave.

​
Checklist

  • Keys in env vars or a secrets manager, never in source or client code.
  • One key per workload, each capped.
  • Rotate by create-then-revoke.
  • Authorization never logged.
  • Key management limited to owner and admin.

Cost Control

Spend caps.

Authentication

Keys and headers.

Privacy-Safe Logging

Keep prompts and keys out of logs.

​
Separate provisioning from inference

Keep application keys at the default admin: false. Store a separate admin key in your provisioning service if you automate key creation and rotation. Set expiry and spend caps explicitly on each new key: these are independent of the caller’s settings. Creation returns the secret once at key.token; list responses never reveal it.