# API reference

Choose the API for the resource you want to manage.

Source: https://docs.minds.sh/docs/api



Minds exposes two distinct interfaces. They have different hosts, credentials, and responsibilities. A dashboard session does not automatically grant authority over every namespace in an Akasha instance.

<Cards>
  <Card title="Minds platform API" href="/docs/api/platform">
    Organizations, instance provisioning, lifecycle, telemetry, billing, and account integration.
  </Card>

  <Card title="Akasha instance API" href="/docs/api/instance">
    Memory, knowledge graphs, data storage, retrieval, learning, models, and engine operations.
  </Card>
</Cards>

## Choose by intent [#choose-by-intent]

| I want to…                               | Use                                  |
| ---------------------------------------- | ------------------------------------ |
| Launch, list, or resize a Mind           | Platform provisioning and management |
| Read account usage or billing state      | Platform billing and usage           |
| Store an event or search context         | Instance memory                      |
| Create a graph edge or query an index    | Instance knowledge graph or vectors  |
| Inspect engine health or a learning task | Instance operations or learning      |

## Download the contracts [#download-the-contracts]

* [Akasha OpenAPI 3.1 document](/reference/instance/openapi.json) — registered HTTP paths, source-derived schemas, and explicit uncertainty notes.
* [Minds platform endpoint catalog](/reference/platform/endpoints.json) — management routes and request/response contract metadata.

## Before your first request [#before-your-first-request]

1. Get the **base URL for the correct interface**. Do not add an instance path to the public marketing hostname.
2. Read its authentication page. Platform session credentials, instance capabilities, operator credentials, and legacy JWTs are not interchangeable.
3. Check the endpoint's request schema and availability. Some registered handlers remain incomplete; the reference calls these out.
4. Confirm the response proves the intended operation. A healthy service, a simulated connection check, or an acknowledgment does not prove data was persisted.

The reference is generated from registered routes and their handlers. It is designed to expose coverage and limitations rather than silently omit unfinished operations.