Authentication

Token Factory uses API keys as Bearer tokens for OpenAI-compatible /v1 requests. Keys carry the sk-oais prefix and inherit their workspace's quotas, billing, and Observability scope.

#Workspace-level controls

#Create a key

1. 1
   Generate a key

   Sign in to Token Factory and open API keys. Enter a descriptive label, such as prod-payments-worker or staging-pipeline, and click Generate.

2. 2
   Choose an expiry

   Optional. A new key never expires unless you say otherwise. Pick 30, 90 or 365 days, or Pick a date… for a specific day up to a year out. A key with an expiry stops authenticating at 23:59 UTC on its last day, so it works through the whole day you choose.

   Ask for longer than the maximum permitted and creation fails with 400 and the code EXPIRY_TOO_LONG — choose a shorter expiry and retry.

3. 3
   Copy the secret once

   The full sk-oais... value is shown only once. Store it immediately in your password manager, CI/CD secret store, or runtime secret manager.

4. 4
   Set it locally

   Use the same environment variable as the Quickstart examples.

   $_macOS / Linux

    

   export OMNIVA_API_KEY="sk-oais..."

   $_Windows PowerShell

    

   $env:OMNIVA_API_KEY="sk-oais..."

New keys use the sk-oais... prefix. Existing key lists show only a masked value (for example sk-oaisf****************************************25xx — first 8 and last 4 visible, rest hidden) so you can identify a key in logs and dashboards without exposing the full secret.

#Key expiry and states

A key in the list is in one of three states.

Keys inside 7 days of expiring are badged Expires soon, which is the window to create the replacement. Nothing rotates automatically — an expiry is a deadline, not a hand-off, so treat the badge as the cue to run through Rotate a key before the date rather than after it.

An expired key fails the same way a revoked or mistyped one does: the request is rejected as unauthenticated, with no field distinguishing "expired" from "invalid". If calls start failing and the key was on a timer, check its date in API keys before assuming the secret is wrong.

#Required headers

Send API keys in the Authorization header.

#Security rules

#Rotate a key

Rotation is create-new, swap, revoke-old — never revoke first.

1. 1
   Create the replacement

   Open API keys, generate a new key, and use a label that includes the workload and rotation date.

2. 2
   Deploy the new secret

   Update the runtime secret in your service, CI/CD pipeline, or local environment.

3. 3
   Verify traffic

   Confirm requests succeed with the new key and check Observability for unexpected errors.

4. 4
   Revoke the old key

   After the new key is live everywhere, click Revoke next to the old key.

#A leaked key

Treat a leaked key as an incident:

1. Revoke immediately in API keys.
2. Generate a replacement and roll it out to every affected environment.
3. Check usage in Observability for unexpected request volume.
4. Audit every surface where the key may have been captured — search for the leaked value or a stable prefix in:
   • Git history: git log -S '<first 12 chars>' and git log -p -- <suspect files>
   • CI/CD build logs (GitHub Actions, GitLab CI, Jenkins console output)
   • Slack and chat history (DMs and channels)
   • Error trackers that capture request headers (Sentry, Datadog, Rollbar)
   • Env-dump endpoints (/health, /debug, dev tools, internal admin pages)
5. Notify your security team using your internal incident process.

#Troubleshooting

#What next