> ## Documentation Index
> Fetch the complete documentation index at: https://datum-4926dda5-docs-api-reference-demo.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# API resources

> The resource and field reference for Datum Cloud services.

This section is the **resource and field reference** for Datum Cloud. It documents the resources each service exposes and the fields you set and read on them — what a resource *is*, not how to accomplish a task with it.

<Info>
  Looking for how-to guides instead? Here's how the references fit together:

  * **API resources** (you are here) — the resource/field reference: what fields a resource has, their types, and what they mean.
  * **[datumctl](/datumctl/overview)** — task-oriented how-to guides for using the CLI. Run `datumctl <command> --help` for the command and flag reference.
</Info>

<Warning>
  The Datum Cloud API is currently **alpha** (`v1alpha`/`v1alpha1`). Resources, fields, and defaults may change in backward-incompatible ways between releases.
</Warning>

## Start with the concepts

Every Datum Cloud resource shares the same shape and workflow, so a handful of ideas apply to *all* of them. Read these first and the per-service pages become quick lookups rather than fresh material each time.

<CardGroup cols={2}>
  <Card title="API conventions" icon="shapes" href="/api/concepts/conventions">
    The declarative model behind every resource — `apiVersion`, `kind`, `metadata`, `spec`, and `status`. Start here.
  </Card>

  <Card title="Object metadata" icon="tag" href="/api/concepts/metadata">
    The shared `metadata` block: names, labels, annotations, and the fields the platform manages for you.
  </Card>

  <Card title="Status & conditions" icon="heart-pulse" href="/api/concepts/status-and-conditions">
    How to read observed state and the standard `conditions` pattern to tell whether a resource is ready.
  </Card>

  <Card title="Scopes" icon="folder-tree" href="/api/concepts/scopes">
    Whether a resource lives inside a **Project** or is shared across the **Platform**, and how that maps to your context.
  </Card>
</CardGroup>

<Tip>
  Three more concept pages round out the shared model: [versioning & stability](/api/concepts/versioning), [resource references](/api/concepts/references), [field formats & types](/api/concepts/field-formats), and [validation & safe changes](/api/concepts/validation).
</Tip>

## Browse by service

Resources are organized by the service that owns them. Services group into three layers: **Foundation** services model who you are and what you own, **Infrastructure** services run and connect your workloads, and **Operations** services govern consumption, billing, and communication.

### Foundation

Model your organizations, projects, access control, and machine identities.

<CardGroup cols={2}>
  <Card title="Resource Manager" icon="sitemap" href="/api/resource-manager/overview">
    Organizations, projects, and the membership that ties people to them.
  </Card>

  <Card title="IAM" icon="lock" href="/api/iam/overview">
    Roles, policy bindings, groups, service accounts, and user invitations that control access.
  </Card>
</CardGroup>

### Infrastructure

Run workloads and connect them to the network.

<CardGroup cols={2}>
  <Card title="Compute" icon="server" href="/api/compute/overview">
    Workloads, deployments, and the instances that run them.
  </Card>

  <Card title="Networking" icon="network-wired" href="/api/networking/overview">
    Networks, subnets, gateways, and HTTP routing resources.
  </Card>

  <Card title="DNS" icon="globe" href="/api/dns/overview">
    Managed DNS zones and records for your domains.
  </Card>

  <Card title="IPAM" icon="diagram-project" href="/api/ipam/overview">
    IP pools, claims, and allocations for address management.
  </Card>
</CardGroup>

### Operations

Govern consumption, pay for what you use, and stay informed.

<CardGroup cols={2}>
  <Card title="Quota" icon="gauge" href="/api/quota/overview">
    Allowance buckets, resource claims, and grants that meter usage.
  </Card>

  <Card title="Billing" icon="credit-card" href="/api/billing/overview">
    Billing accounts, account bindings, and payment methods.
  </Card>

  <Card title="Telemetry" icon="chart-line" href="/api/telemetry/overview">
    Export policies that ship metrics and logs to your own tooling.
  </Card>

  <Card title="Notification" icon="bell" href="/api/notification/overview">
    Contacts, contact groups, and the emails and broadcasts sent to them.
  </Card>
</CardGroup>

<Note>
  **[Platform resources](/api/platform/overview)** collects the platform-provided and reference resources you point at rather than compose — the service catalog (Services, entitlements, and consumers), classes like `DNSZoneClass` and `GatewayClass`, `IPPool`s that claims allocate from, and email templates.
</Note>

## How to read these pages

Each resource page follows the same structure, and each part is explained in depth on its concept page:

* **Identity** — the resource's kind, [API group and version](/api/concepts/versioning), and [scope](/api/concepts/scopes) (**Project** or **Platform**).
* **Spec fields** — the fields you set to declare desired state. See [API conventions](/api/concepts/conventions) for the `spec`/`status` model, [field formats & types](/api/concepts/field-formats) for how the `Type` and `Required` columns read, and [object metadata](/api/concepts/metadata) for the shared `metadata` block every page omits.
* **Status** — the read-only fields the platform reports back, including the shared [status & conditions](/api/concepts/status-and-conditions) pattern. Fields that point at other resources follow the [resource references](/api/concepts/references) convention.
* **Usage** — how to create, read, and inspect the resource with `datumctl`.

Manifests are applied with `datumctl apply -f`, and you can read or inspect resources with `datumctl get` and `datumctl describe` — see [changing resources](/datumctl/resources/changing) and [reading resources](/datumctl/resources/reading). Every write is checked first; see [validation & safe changes](/api/concepts/validation).

```bash theme={null}
datumctl apply -f my-resource.yaml
datumctl get <resource>
datumctl describe <resource> <name>
```

<Tip>
  Field types and required markers throughout this reference come straight from the live API schema, which you can also explore from the CLI with `datumctl explain`.
</Tip>