How this reference is generated
These pages are generated from the OpenAPI specifications the services are built and verified against, not written by hand alongside them. An operation appears here because it exists, with the request and response shapes the service actually implements — including the error responses, which are documented rather than left to be discovered.Conventions
Versioning. Every path is prefixed/v1.
Identifiers. Resource responses expose canonical identities. UUID resource paths use the returned
id; request reference fields accept only the kinds declared by their operation.
See Resource references for scoped names, nested CRNs,
image versions, exact list filters and fetching a resource by any reference.
Organization-scoped CRNs require the authenticated organization context.
Errors. Failures return a JSON body with a stable, machine-readable code.
Match on the code, not on the human-readable message, which may change.
Faults. Resources that run work in the background always include faults:
an array of active observations, or [] when none remain. See
Resource faults for the array, ordering, recovery and how
severity maps onto status.
Idempotency and async work. Operations that hand off to a background
workflow answer 202 Accepted rather than pretending the work is done. Poll the
resource until it reaches a terminal state; a 202 followed by a read that
still shows the old state is the contract working, not a bug.
Pagination. List operations page. Follow the pagination fields in the
response rather than assuming you got everything.
Getting started
Authentication
Bearer tokens, account role sessions, and where credentials come from.
Regions and endpoints
Which host each service answers on, and which are global.
Quickstart
A working authenticated request, end to end.
CLI
Use the APIs from your terminal.