Skip to main content

​
Pointing the SDK at your deployment

Both can also be passed to the constructor. ROTASCALE_URL is required and the client raises without it, because there is no default and a governance layer that silently talks to the wrong deployment is worse than one that will not start.

​
Where the key comes from

API keys are issued in the console, scoped to a workspace, and shown once. The platform stores a hash. If you lose it, reissue it; nobody can recover it for you, including us, because it never left your deployment.
An API key authenticates a service, not a person. It says which system is talking. It does not say who is accountable for what the agent does. That is what a grant is for, and the two are deliberately separate.

​
Workspaces

A workspace is the isolation boundary for agents, grants and records. A key scoped to one cannot read another.

​
Per-action credentials

Some grants mint a short-lived credential for the specific action being authorised, when the grant names an audience. It comes back on the Decision and is for the downstream system, not for Rotascale. This exists so that the thing an agent presents to your payment rail is bounded by the same authority the gates just checked, rather than a long-lived secret sitting in the agent’s environment.

​
Tokens instead of keys

ROTASCALE_TOKEN accepts a bearer token where your deployment federates identity rather than issuing keys. Set one or the other; the client raises if neither is present, and the error names both.

​
What we never see

No key, token or credential reaches Rotascale. The platform runs single-tenant inside your environment, so “our” side of this sentence does not exist. See Deployment.