Changelog

API keys now carry clearer scopes and usage attribution, and workloads can own their credentials through service accounts.

Service accounts

A service account is a machine identity for a workload rather than a person, so billing-sync, nightly-audio-renderer, or support-bot-runtime can own its own credentials and limits. It owns one or more API keys and carries the scope ceiling those keys inherit — tighten the account and every inherited key tightens; delete the account and the whole credential family is revoked.

Service-account keys support zero-downtime rotation: rotate the key, deploy the new secret, and let the old one expire after the grace window (set it to 0 to cut over immediately). The rotation call is idempotent.

For short-running jobs, a designated minter key can call POST /v1/auth/service-account-keys to mint a child credential with a required TTL and a weaker-or-equal scope set. A child key can never exceed the minter’s scopes, expires within 24 hours, and cannot mint further keys — spend and usage still roll up to the same service account.

Scopes and attribution

The Audio API now uses audio:all for speech generation. Voices use the standard voices:read, voices:write, and voices:all tiers. Service-account keys inherit the account’s ceiling, so a TTS-only renderer can hold audio:all and nothing else.

Usage events now carry the API key or service-account identity that caused them. The console can label usage by credential, and the key directory keeps enough metadata for reports to stay readable after keys rotate — when a bill spikes, you can ask which key did it, not just which workspace.

See the service accounts guide for the full setup flow.