Compute management API contracts

Choose the operation family before calling an account operation, then check its exact method, path, scope, and refusal contract. Account administration and Compute work use different permissions. A key that can submit a job does not automatically have access to team membership, billing records, or integration settings.

An agent or application may prepare a management request from these tables, but only the authorized account administration flow grants the operation. A request body cannot create that authority.

Keep work grants separate

The customer work-key grant set contains jobs:read, jobs:write, batches:write, quotes:read, models:write, and usage:read. A particular key receives only its granted scopes, not necessarily all six.

The administration scopes in the tables below are outside that mintable work-key set. Use the authorized account administration flow for those actions. Adding an actor, role name, or requested scope to a JSON body does not grant that permission.

These tables show the declared method, path, and required scope for each operation. They are not a grant, a list of callable SDK features, or a substitute for the operation's request and response schemas. In particular, the declarations below do not define a universal describe → plan → apply lifecycle.

Account, approvals and team operations

Operation ID	Method and path	Required scope
`accountSetup`	`POST /v1/account/setup`	`account:write`
`listApprovals`	`GET /v1/approvals`	`approvals:read`
`decideApproval`	`POST /v1/approvals/{id}`	`approvals:write`
`showLimits`	`GET /v1/limits`	`limits:read`
`spendPolicy`	`POST /v1/spend-policy`	`limits:write`
`referralStatus`	`GET /v1/referral-status`	`referral:read`
`listTeamInvites`	`POST /v1/team-invites`	`team:write`
`listTeamMembers`	`GET /v1/team-members`	`team:read`

Use the declared method rather than guessing from the operation name. Despite its name, listTeamInvites is declared as POST with team:write, not GET with a read grant.

An approval decision and a job submission are separate actions. A work quote is not permission to change spend policy, invite a member or administer a key.

Billing records and payment actions

Operation ID	Method and path	Required scope
`pricing`	`GET /v1/pricing`	`quotes:read`
`billingProfile`	`GET /v1/billing-profile`	`billing:read`
`listExports`	`GET /v1/exports`	`billing:read`
`getExport`	`GET /v1/exports/{id}`	`billing:read`
`listInvoices`	`GET /v1/invoices`	`billing:read`
`getInvoice`	`GET /v1/invoices/{id}`	`billing:read`
`getPayment`	`GET /v1/payments/{id}`	`billing:read`
`openPayment`	`POST /v1/payments/{id}/open`	`billing:write`
`purchaseOrderPolicy`	`GET /v1/purchase-order-policy`	`billing:read`
`listStatements`	`GET /v1/statements`	`billing:read`
`getStatement`	`GET /v1/statements/{id}`	`billing:read`

Reading usage with usage:read does not grant billing:read or billing:write. Likewise, a payment-related operation name does not prove that money moved. Keep the invoice, payment action, and confirmed payment distinct.

Finance connections and webhook operations

Operation ID	Method and path	Required scope
`listFinanceConnections`	`GET /v1/finance-connections`	`finance:read`
`financeSchema`	`GET /v1/finance-schema`	`finance:read`
`financeMappings`	`POST /v1/finance-mappings`	`finance:write`
`listFinanceSyncEvents`	`GET /v1/finance-sync-events`	`finance:read`
`listWebhookEndpoints`	`GET /v1/webhook-endpoints`	`webhooks:read`
`getWebhookEndpoint`	`GET /v1/webhook-endpoints/{id}`	`webhooks:read`
`rotateWebhookSecret`	`POST /v1/webhook-endpoints/{id}/rotate-secret`	`webhooks:write`

Finance mapping changes and webhook secret rotation cross different permission boundaries. Neither follows from permission to read a job. Do not place cloud credentials, webhook secrets or billing authority inside an ordinary work request.

Handle a local client refusal safely

SDK_CONTRACT_UNAVAILABLE is conditional on the selected client and method. TypeScript's LithiComputeClient.pricing() implements its compatibility wire contract; the legacy per-service projection returns a typed unavailable response and next action. Use informational token rates for planning (GET https://lithi.ai/api/public/compute/pricing for structured rates) and the signed quote for exact work. SDK method support does not make an old pricing list the current tariff. Other clients can expose a different support set; check their operation metadata before calling.

When the selected method reports SDK_CONTRACT_UNAVAILABLE, treat it as a client-contract refusal, not HTTP rate limiting or evidence that an account change occurred. Stop the attempted call. Check the exact client and operation contract; do not invent a body, switch to a guessed endpoint or widen a work key to bypass it.

For support, retain the operation name, client version and error code. Do not include a bearer key, raw financial records or a secret-bearing request. A method appearing in autocomplete is not proof that it can complete an account action.

Interpret HTTP errors separately

When an authorized HTTP operation returns a typed error, the API description defines the error envelope as follows. This example is synthetic:

{
  "ok": false,
  "error": { "code": "FORBIDDEN" },
  "p_next_action": "none"
}

UNAUTHENTICATED and FORBIDDEN are different from a local SDK_CONTRACT_UNAVAILABLE exception. Preserve the response status and exact error code. Do not assume every error includes a message, request identifier or the value that failed validation.

A missing request schema does not mean a POST accepts an arbitrary object. An error response declaration does not define a successful response shape. Only enable a caller when its exact request, response, identity and recovery contracts are available to that caller.

Use the canonical Compute OpenAPI document to check the operation declaration. Keep it as the machine-readable authority rather than building an independent API from these permission tables.