> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Management API reference
description: >-
  The thirteen Compute management resource families, the minimum operations each supports, the one
  shared lifecycle, and who may call a management operation.
route: /docs/compute/reference/management-api
page_id: docs-compute-reference-management-api
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: 'Platform engineers and administrators configuring a Compute organization'
voice: D
reader_question: 'Which management resources exist, and what can I do to each one?'
primary_action: Plan a change before you apply it
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-reference-management-api-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## The thirteen resource families

Management is separate from work. It configures your organization; it never submits a job.

| Resource family | Minimum operations |
| --- | --- |
| Organization and account | describe, get, plan or update, read back |
| Projects and subaccounts | list, get, plan, create, update, archive, read back |
| Members, invitations and grants | list, get, plan, invite, grant, suspend, remove, read back, events |
| Identity sync and role mappings | describe, plan, apply, pause, revoke, read back, events |
| Personal, service and automation identities and keys | plan, create, rotate, revoke, read back |
| Spend and approval | get, plan, apply, request, decide, expire, read back |
| Sources and credentials | describe, list, get, plan, register, test, revoke, read back |
| Destinations and delivery | describe, list, get, plan, register, test, revoke, read back, events |
| Workflow profiles and rubrics | describe, list, get, plan, create, version, retire, read back |
| Schedules and webhooks | describe, list, get, plan, apply, pause, resume, replay, revoke, read back, events |
| Finance and cost allocation | describe, list, get, inspect, plan, apply, export, reconcile, read back |
| Statements, invoices and payment | list, get, export, open hosted action, read status, reconcile |
| Audit and receipts | list and get, with stable cursors and content-free projections |

## One lifecycle across every family

Every family follows the same order: describe, inspect, plan, approve where required, apply, read back, events, revoke.

Plan first. The plan tells you what would change and whether an approval is needed. Apply then returns a result you read back, rather than a result you assume.

Re-applying the same change returns its prior verified result. Rollback never means undoing an invitation, an external write or a payment.

## Who may call a management operation

Two profiles exist. A person signs in and works in a human portal session. A machine uses a separately admitted management service identity.

A work key cannot do either. Management scopes are never mintable on a work key, so an automation that submits jobs cannot quietly change spend or add a destination.

## Secrets are handled once

An identity key's plaintext is shown once only. Store it then, or rotate to get a new one.

A source holds a secret reference, never the secret itself. Credentials are stripped before manifest, job and outbox persistence.

## There is no debit operation

Statements, invoices and payment expose list, get, export, open hosted action, read status and reconcile. There is no debit operation. Lithi does not pull money from your account.

The hosted payment action reports `unavailable`, `ready`, `opened`, `expired` or `revoked`. Only a current Mercury read-back advances the Lithi payment projection to paid. A `Paid` label in your ERP is an annotation, never settlement.

## Where the exact paths are published

Every management path, request schema, response schema and per-operation error schema is generated into the API description you download from developer settings in the portal.

The portal exposes the same resources for a person. See [how to read an applied state](/docs/compute/reference/states) when a plan comes back partial.