Skip to main content
Before you can create or update a resource, you need to know two things: which resource types Datum Cloud offers, and what fields each type accepts. datumctl answers both questions directly from the API server, so what you see always reflects the exact version of the platform you are connected to. Three commands cover discovery:
These commands read from the control plane for your currently configured context. Make sure you are logged in (see Logging in) and have an organization or project selected first — pass --organization your-org-id or --project your-project-id, or set a default context. See Contexts & scoping for how that scope is chosen.

​
List available resource types

datumctl api-resources prints a table of every resource type the current control plane supports. It is the starting point for discovering what you can manage with datumctl get, datumctl apply, and datumctl explain. The table includes each type’s short names, API group, whether it is namespaced, and its kind.
The list is fetched fresh from the server on each run. To reuse a locally cached copy, pass --cached.

​
Narrow and sort the list

For a busy control plane, filter and reshape the output to find what you need:
The short names shown here are the same aliases you can use anywhere a resource type is expected — for example in datumctl get, datumctl explain, or datumctl describe.

​
List API versions

datumctl api-versions prints every API group/version combination the current control plane exposes, one per line in the form group/version (for example, networking.datumapis.com/v1alpha).
This is the value you place in the apiVersion field of a manifest. Use api-versions when you need the group/version string, and api-resources when you also want to see the individual resource types within each group.

​
Inspect a type’s schema

Once you know a type exists, datumctl explain shows its schema and field-level documentation. Information is retrieved from the API server in OpenAPI format, so it always matches the platform version you are connected to.
Fields are referenced with dot notation — TYPE.fieldName.subFieldName — so you can drill into any part of the tree:
To see the whole schema tree at once instead of one level at a time, use --recursive:
If you prefer the OpenAPI v2 rendering, request it explicitly:

​
From discovery to a manifest

Discovery feeds directly into authoring manifests for datumctl apply and datumctl create. A typical flow:
1

Find the type

Run datumctl api-resources to confirm the resource type exists and note its kind and API group.
2

Get the apiVersion

Run datumctl api-versions to find the exact group/version string for that group.
3

Learn the fields

Run datumctl explain <type> (add --recursive for the full tree) to see which fields are required and what they do.
4

Write and validate the manifest

Author your YAML with the apiVersion, kind, and spec fields you discovered, then validate it against the server before persisting.
datumctl explain <type>.spec is the fastest way to see exactly which fields belong under spec when you are filling out a new manifest.

​
Search across your resources

When you know roughly what you’re looking for but not its kind or exact name, use the search plugin. It searches your resources by name and kind, and returns the best matches first. To install it, run datumctl plugin install search.
To narrow the results to one or more kinds, add --kind, such as --kind Workload --kind HTTPProxy. To see which kinds are searchable, run datumctl search kinds. For scripts, add -o json.

​
Check which services your project can use

Some Datum services, such as Compute, must be enabled for a project before you can create their resources. To see every service and whether it’s enabled for your current project, run the following command:
The state of each service is Active, pending approval, NotRequested, or denied. To request a service, run datumctl services enable SERVICE_NAME. Some services need approval from Datum, so add --wait to wait for the answer, or check back later with datumctl services status SERVICE_NAME. To explain why you need a service, add --message.
  • Changing resources — author, apply, and edit resources once you know which types exist and what fields they take.
  • Reading resources — list, retrieve, and inspect resources of the types you discover here.
  • Output formats & scripting — render this discovery output as JSON or YAML and pipe it into other tooling.
  • Logging in — sign in before querying the control plane.
  • datumctl api-resources --help, datumctl api-versions --help, and datumctl explain --help for the full flag reference.
Last modified on November 3, 2026