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
Today, control surfaces sit at the workspace level, not the key level.
Scoped at workspace (apply to every key in the workspace):
- Token quotas and rate limits (RPM, TPM)
- Billing and spend caps
- Observability — usage, latency, and error metrics
Not scoped per key (no support today):
- Per-key scopes or permissions
- Per-key RPM / TPM overrides
- Per-key expiration dates
- Per-key spend caps
If you need per-key isolation, use a separate workspace per workload.
Authorization: Bearer sk-oais...
Full secret appears once at creation. Lists show a mask like sk-oa**********25xx.
Selected workspace context.
#Create a key
- Generate a key
Sign in to Token Factory and open API keys. Enter a descriptive label, such as
prod-payments-workerorstaging-pipeline, and click Generate. - 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. - Set it locally
Use the same environment variable as the Quickstart examples.
New keys use the sk-oais... prefix. Existing key lists show only a masked value (for example sk-oa**********25xx — first 4 and last 4 visible, rest hidden) so you can identify a key in logs and dashboards without exposing the full secret.
Never commit API keys. Use environment variables, secret managers, or your platform's secret bindings. Leaked keys end up in scrapers within minutes.
#Required headers
Send API keys in the Authorization header.
| Header | Required | Notes |
|---|---|---|
Authorization: Bearer <key> | Yes | Use the full sk-oais... API key. |
Content-Type: application/json | Yes (POST) | Required for JSON request bodies. |
#Security rules
Create the replacement, deploy it, verify traffic, then revoke the old key.
Send keys in headers only. URLs can be logged by browsers, proxies, and monitoring tools.
#Rotate a key
Rotation is create-new, swap, revoke-old — never revoke first.
- Create the replacement
Open API keys, generate a new key, and use a label that includes the workload and rotation date.
- Deploy the new secret
Update the runtime secret in your service, CI/CD pipeline, or local environment.
- Verify traffic
Confirm requests succeed with the new key and check Observability for unexpected errors.
- 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:
- Revoke immediately in API keys.
- Generate a replacement and roll it out to every affected environment.
- Check usage in Observability for unexpected request volume.
- 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>'andgit 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)
- Git history:
- Notify your security team using your internal incident process.
#Troubleshooting
401 Unauthorized: confirm the request includesAuthorization: Bearer sk-oais...with the full key.403 Forbiddenwhile managing keys: confirm you are signed in with a workspace context that can manage API keys.- Unsupported sign-in provider: sign in with a supported workspace identity provider that can issue a JWT for API key management.
- Key limit reached: revoke an unused key before generating a replacement.