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.

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 — task-oriented how-to guides for using the CLI. Run datumctl <command> --help for the command and flag reference.

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

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.

API conventions

The declarative model behind every resource — apiVersion, kind, metadata, spec, and status. Start here.

Object metadata

The shared metadata block: names, labels, annotations, and the fields the platform manages for you.

Status & conditions

How to read observed state and the standard conditions pattern to tell whether a resource is ready.

Scopes

Whether a resource lives inside a Project or is shared across the Platform, and how that maps to your context.

Three more concept pages round out the shared model: versioning & stability, resource references, field formats & types, and validation & safe changes.

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.

Resource Manager

Organizations, projects, and the membership that ties people to them.

IAM

Roles, policy bindings, groups, service accounts, and user invitations that control access.

Infrastructure

Run workloads and connect them to the network.

Compute

Workloads, deployments, and the instances that run them.

Networking

Networks, subnets, gateways, and HTTP routing resources.

DNS

Managed DNS zones and records for your domains.

IPAM

IP pools, claims, and allocations for address management.

Operations

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

Quota

Allowance buckets, resource claims, and grants that meter usage.

Billing

Billing accounts, account bindings, and payment methods.

Telemetry

Export policies that ship metrics and logs to your own tooling.

Notification

Contacts, contact groups, and the emails and broadcasts sent to them.

Platform resources 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, IPPools that claims allocate from, and email templates.

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, and scope (Project or Platform).
• Spec fields — the fields you set to declare desired state. See API conventions for the spec/status model, field formats & types for how the Type and Required columns read, and object metadata for the shared metadata block every page omits.
• Status — the read-only fields the platform reports back, including the shared status & conditions pattern. Fields that point at other resources follow the resource 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 and reading resources. Every write is checked first; see validation & safe changes.

datumctl apply -f my-resource.yaml
datumctl get <resource>
datumctl describe <resource> <name>

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.