elevenlabs.providers.sgit.ai / experiments / Key scope and quota probe
Key scope and quota probe
Eight GET requests, no generation, no spend. What comes back tells you what your key may do. What does not come back — anywhere in the API — is any way to cap what it may cost. That absence is the whole argument of this site, made empirically rather than asserted.
Your own full key, in your own browser, bounded only by your plan's monthly quota. That is pattern 0 with a ceiling: the narrow case where it is defensible — the key's owner, testing their own key, on their own device — and not a pattern to publish. No key ships in this page: the field below is empty until you fill it.
ElevenLabs offers no per-key spend limit for text to speech, so nothing here caps what a leaked key could cost you except the account's own quota. Use a key scoped in the dashboard to the endpoints this lab needs, and forget it when you are done. The version of this page with no key box at all is pattern three, and it does not exist yet.
1 · Probe — reads only, no generation, no spend
Every request this lab makes is a GET. Nothing here generates audio and nothing here
costs a character. What comes back tells you what your key may do — and, more usefully, what nothing in
the API will tell you: how much it may spend.
2 · What the key reaches
| Endpoint | What it would grant | Status | Reading |
|---|
3 · The quota — the only bound there is
Look for what is missing. The subscription object reports characters used, characters allowed and the reset date — for the account. There is no per-key spend field in it, because there is no per-key spend limit to report. Scoping a key restricts which of the rows above it can reach; it does not cap what it can cost. That is the difference between scoped and bounded, and it is the reason pattern 1 has no implementation here.
4 · Log
Scoped is not bounded
A key can be restricted in the dashboard to the endpoints it needs. A key for a render pipeline needs text-to-speech and voices-read; it does not need dubbing, voice creation, or history — and history is worth thinking about, because it holds the text of everything the account has ever generated.
Scoping limits what a leaked key can do. It does nothing at all to limit how much of the account's quota it can burn vendor docs 5 Sep 2026. There is no per-key spend limit, no daily window, and nothing that resets faster than the billing cycle vendor docs 5 Sep 2026.
That is the difference between this vendor and the sibling one, and it is not a matter of degree. On the sibling provider a key carries a number you chose, and when the spend reaches it the platform refuses — we have the 402 to prove it verified 3 Sep 2026. Here, the only refusal comes when the account's month runs out.
How to read the probe
- 200 — the key reaches this class of endpoint. If you did not intend it to, tighten the key in the dashboard and re-run.
- 403 — scoped out, or not on this plan. On a narrowly-scoped key, most rows should be 403; a table of 200s means a key that can do everything, which is what a leak would then be able to do.
- 401 on everything — the key is wrong, revoked, or sent under the wrong header name; auth is
xi-api-key, notAuthorizationvendor docs 5 Sep 2026.
The tile that says "none"
The fourth tile in section 3 has no data behind it, because there is no field to read. Every other number on that row comes from GET /v1/user/subscription: characters used, characters allowed, the reset date — all account-level vendor docs 5 Sep 2026. The API has no concept of a per-key budget, so a lab cannot show you one.
That is the empirical form of the claim the report makes in prose, and it is why pattern 1 is marked unavailable in the comparison rather than merely discouraged.