Compute
Authenticate a Compute client
Compute releases work keys, human portal sessions and management service identities. Learn which one your client needs, how to store it safely, and how to confirm the account it resolved to.
Before you start
You need an account, a member role, and a decision about what this client will do. That last part chooses your credential for you.
If the client submits work, it needs a work key. If it changes configuration, it needs management authority, and those are never the same credential.
Choose the released credential
Four credential kinds are released today. Each authenticates a different actor.
| Credential | Who or what it authenticates | What it can never do |
|---|---|---|
| Personal work key | One named person's own submissions | Administer accounts, identities, destinations or finance |
| Service or automation work key | One agent, script or scheduled automation | Anything outside its six work scopes |
| Human portal session | A signed-in member, in the portal | Expand the work tool set or bypass an approval |
| Management service identity | One automation doing administration | Hold more authority than the person who owns it |
A work key holds six work scopes and nothing else. Management scopes are never mintable on a work key, so no rotation, no re-issue and no support request converts one into the other.
Set up your credential store
Store the secret in your operating system credential store or your team's secret manager. Give the client a reference to it.
Never place a secret on a command line, in a committed file, in a log line, or in a message to support. Support will never ask you for one.
Your base URL and current API version appear in the portal under developer settings, and in the OpenAPI description you download. Do not hard-code values copied from an example.
Confirm the selected account
A credential that works is not proof it is the credential you meant. Check which account it resolved to before your first real submission.
lithi doctor
Then read the response envelope on any call. It carries a request_id, the operation, the contract release, the typed state, an evidence class, an observed_at time and a valid_until time.
If valid_until has passed, the read is stale. Read again rather than trusting it.
Know how each surface differs
The three surfaces authenticate the same identity in three different shapes.
A REST call is stateless. Every request carries the credential, and nothing is remembered between calls.
An MCP session authenticates once, then stays open. It exposes exactly five work tools: lithi.quote, lithi.run, lithi.batch, lithi.status and lithi.result.
Local helpers such as lithi.plan() and lithi.recommend() run beside those five. They neither quote, admit nor run paid work, so they never spend anything. Check what a work key can hold if you expected a sixth tool.
A portal session authenticates a person, in a browser, for management work. It never gains work tools, and a work key never gains portal authority.
Confirm success
lithi doctor reports the account you expected. One small status call returns an envelope naming that account and a current valid_until.
If the account is wrong, your client picked up a different stored credential. Fix the reference rather than issuing a new key.
When authentication refuses
A refusal names a safe reason and a concrete next action, and the two belong together.
An expired or revoked credential needs a new one; issue it deliberately rather than reusing an old secret. A credential that is valid but lacks the scope refuses on authority, and the fix is a grant, not a retry.
CANONICAL_ADMISSION_LIMITED means the key or account is not authorized to make that request. Check the scope before you assume a service problem.