Authentication

Every request carries your organization’s API key as a Bearer token. Keys are shown once at mint time and stored hashed on our side — treat them like passwords.

Bearer token

Authorization header
Authorization: Bearer oo_live_<secret>

# Keys must start with oo_live_
# Invalid format returns 401 invalid_key

Member attribution

For per-member soft limits and usage breakdowns, pass your internal user UUID. This does not forward identity to upstream model providers.

Optional header
X-Member-User-Id: <uuid>

Scopes

chat

POST api-v1-chat

images

POST api-v1-images

video

POST api-v1-video, GET poll

audio

POST api-v1-audio

usage

GET api-v1-models, api-v1-usage

Model allowlists

Keys can optionally be pinned to specific model IDs at mint time — useful for single-purpose service keys or limiting blast radius.

Key hygiene

  • Store keys in a secrets manager, never in client-side source committed to git.
  • Rotate keys if exposed; revoke immediately in the admin console.
  • Use separate keys per environment (staging vs production).
  • See Errors & limits for rate-limit tiers.