API keys now carry clearer scopes and usage attribution

Speechify API keys now have clearer scopes and better usage attribution. The change is mostly about making production operations less weird: a key should say what it can do, usage should say which key caused it, and spend reports should be traceable to a real workload.

This is not glamorous. It is the release you want when something is spending money at 2am.

What changed for scopes?

The Audio API now uses audio:all for speech generation. Voices moved into the usual read, write, all tiering with voices:read, voices:write, and voices:all.

Service-account keys inherit the service account’s ceiling, so a TTS-only renderer can hold audio:all and nothing else. An internal support bot can have a different account. A batch worker can have its own account. Each workload gets the shape it needs instead of sharing one broad key.

The API authorization layer now enforces read/write symmetry more consistently too. If a key can read a thing, that does not mean it can mutate it. If a route is deliberately not scope-gated, that is now explicit in code and tests rather than accidental.

What changed for usage attribution?

Usage events now carry the API key or service-account identity that caused them. The console can label usage by credential, and the API key directory keeps enough metadata to make reports readable after keys rotate.

In plain terms: when a bill spikes, you can ask which key did it instead of just asking which workspace did it.

Why this matters

Scopes reduce the damage from leaked credentials. Attribution reduces the time it takes to find a runaway workload. Together, they make API keys feel like production infrastructure rather than copied secrets in a .env file.

If you run more than one workload on Speechify, give each one its own key or service account. Future-you will thank you when the usage chart has names instead of mystery traffic.