Per-client API access
The three-layer gate that decides whether a client's API works, the exact 403 they see, and why nothing is cached.
Whether a client can use the v1 API is decided by three switches. All three must be on. Any one off denies access.
| Layer | Who controls it | Default |
|---|---|---|
| Platform master switch | The platform operator | Off |
| Per-organisation toggle | The platform operator | On |
| Per-client entitlement | You, or the client's plan | Inherits the plan |
Your layer is the third: the per-client API access override in the client's Limits editor — Inherit, On, or Off. Inherit falls back to the client's plan flag.
What the client sees when it is off
Both key issuance and the /api/v1 auth gate return 403. In the API the message is:
API access is not enabled for this workspace.In their dashboard:
API access is not enabled for your account — contact your provider.That wording is deliberate: it sends them to you, not to the platform.
Nothing is cached
The gate is resolved live on every request, so flipping any layer takes effect immediately — including on keys that already exist. Turning a client's access off stops their existing keys on the next call; turning it back on restores them without reissuing anything.
Debugging a client's 403
Work down the list in order:
- 1Is your override set to Off? Check the Limits editor.
- 2Is it Inherit, with a plan that has no API access? Set it to On, or move
the client to a plan that includes it.
- 3Are the other two layers on? The platform master switch is off by
default. If every workspace you manage is seeing a 403, that is the layer to ask the platform operator about.
Shared with the platform console
Your per-client override writes the same value a platform admin can set from their Organizations page. Both consoles read and write one effective value — there is no separate per-console state, so it is last-writer-wins between them.
Where to go next
- API authentication — the client-facing
view of the same gate.
Last updated