Skip to content

Automation Service API Reference

Reference · Updated Sep 2026

Coming from another cloud?

▸AWS·Stacks

Stackshigh

  • Quake AI offers Heat (legacy OpenStack orchestration) and recommends OpenTofu for new IaC work; EKS uses declarative console/CLI.
  • EKS Auto Mode automates data plane; Quake AI uses OpenTofu modules for infrastructure provisioning.
  • CloudFormation stacks are managed via AWS-specific REST API (e.g., cloudformation.us-east-1.amazonaws.com) requiring AWS SigV4 auth, while Heat (legacy) uses OpenStack Identity API v3 (keystoneauth) and OpenTofu uses the OpenStack provider with application credentials. Migrators notice different endpoint discovery and auth flows.
  • Stacks support StackSets for cross-region/account deployment; Heat has no equivalent. OpenTofu workspaces offer a different multi-environment pattern.
AWS docs ↗
▸Azure·Resource Manager deployment (deployment)

Azure Resource Manager deployment (deployment)high

  • Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
  • Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
  • Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
  • Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.
Azure docs ↗
▸DigitalOcean·API

DigitalOcean APIhigh

  • Uses REST API over HTTPS with Bearer token authentication via personal access tokens, not OpenStack's Keystone token-based auth.
  • Base URL https://api.digitalocean.com/v2, incompatible with OpenStack APIs like Nova/Neutron.
  • Scoped permissions tied to granular API scopes based on team roles, unlike OpenStack role/project assignments.
  • Rate limits: 5000/hour, 250/minute.
DigitalOcean docs ↗
▸Google Cloud·Deployment Manager

Deployment Managerhigh

  • Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
  • Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
  • Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
  • No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.
Google Cloud docs ↗
▸Hetzner·Cloud API

Cloud APIhigh

  • Proprietary REST API over HTTPS with Bearer token auth, not OpenStack Identity API (keystone) endpoints or mechanisms.
  • Base URL https://api.hetzner.cloud/v1/ with resource-specific endpoints (e.g., /servers) vs OpenStack service endpoints (nova, cinder).
  • No multi-project handling in single auth; separate per-project tokens vs keystone scopes/projects.
  • Missing identity/catalog endpoints; no service discovery via API.
Hetzner docs ↗

Automation service API reference

The Automation API reference documents every Heat endpoint with curl examples.

See https://docs.openstack.org/api-ref/orchestration/index.html.

These endpoints cover stack management, resource management, event tracking, and template validation on the OpenStack Heat backend. The placeholders {stack_name}, {stack_id}, {resource_name}, {event_id}, and {resource_type} in the paths below stand for the actual names and IDs of your stacks, resources, events, and resource types.

Base URL#

Every Heat API call is rooted at the project-scoped orchestration endpoint:

https://orchestration.<region>.rumble.cloud/v1/{project_id}

The orchestration public endpoint in your service catalog already includes the /v1/{project_id} segment, so read the base URL from the catalog rather than assembling it by hand. Every path in this reference is relative to this base: a path shown as /stacks is {base}/stacks. A request that omits /v1/{project_id} returns 404 Not Found.

Required headers#

HeaderWhenValue
X-Auth-TokenEvery callA Keystone identity token. Calls without it return 401 Unauthorized.
Content-TypePOST, PUT, PATCHapplication/json
AcceptRecommendedapplication/json

Endpoints#

All paths are relative to the base URL. The success column lists the HTTP status returned on a normal request.

MethodPathSuccessDescription
GET/stacks200List stacks
POST/stacks201Create a stack
GET/stacks/{stack_name}/{stack_id}200Show stack details
PUT/stacks/{stack_name}/{stack_id}202Replace a stack with a full template
PATCH/stacks/{stack_name}/{stack_id}202Partial stack update
DELETE/stacks/{stack_name}/{stack_id}204Delete a stack
GET/stacks/{stack_name}/{stack_id}/resources200List stack resources
GET/stacks/{stack_name}/{stack_id}/resources/{resource_name}200Show stack resource details
GET/stacks/{stack_name}/{stack_id}/events200List stack events
GET/stacks/{stack_name}/{stack_id}/resources/{resource_name}/events/{event_id}200Show stack event details
GET/stacks/{stack_name}/{stack_id}/template200Show stack template
POST/validate200Validate a template
GET/resource_types200List resource types
GET/resource_types/{resource_type}200Show resource type details (the schema)
GET/resource_types/{resource_type}/template200Get a resource type template

PUT and PATCH return 202 Accepted: Heat applies the change asynchronously, so poll the stack status to confirm completion. PUT requires the full template; PATCH applies only the keys supplied in the request body and leaves unspecified parameters at their current values.

Stack event details#

Heat does not serve a single event at the stack-level /events/{event_id} path; that path returns 404 for every event ID. To fetch one event, first call GET /stacks/{stack_name}/{stack_id}/events. Each entry in the response carries a resource_name. Use it to build the resource-scoped detail path:

GET /stacks/{stack_name}/{stack_id}/resources/{resource_name}/events/{event_id}

Resource type schema#

GET /resource_types/{resource_type} returns the schema directly in its response body. Heat does not expose a separate /resource_types/{resource_type}/schema endpoint. The body contains properties, attributes, and support_status:

JSON
{
  "resource_type": "OS::Heat::RandomString",
  "properties": {
    "length": {
      "type": "integer",
      "description": "Length of the string to generate.",
      "default": 32,
      "required": false,
      "constraints": [{ "range": { "min": 1, "max": 512 } }],
      "update_allowed": false,
      "immutable": false
    }
  },
  "attributes": {
    "value": {
      "description": "The random string generated by this resource.",
      "type": "string"
    }
  },
  "support_status": {
    "status": "SUPPORTED",
    "message": null,
    "version": "2014.1",
    "previous_status": null
  }
}

Response envelopes#

Successful responses wrap their payload in a top-level key. Parse the envelope that matches the request:

ResponseEnvelope
GET /stacks{ "stacks": [ ... ] }
POST /stacks, GET/PUT/PATCH /stacks/{stack_name}/{stack_id}{ "stack": { ... } }
GET /stacks/{stack_name}/{stack_id}/resources{ "resources": [ ... ] }
GET /stacks/{stack_name}/{stack_id}/events{ "events": [ ... ] }
GET /stacks/{stack_name}/{stack_id}/templatethe raw template document
GET /resource_types{ "resource_types": [ ... ] }
GET /resource_types/{resource_type}{ "resource_type": "...", "properties": { ... }, "attributes": { ... }, "support_status": { ... } }

Errors#

Heat returns two error envelope shapes. Keystone produces the authentication error; Heat produces the rest.

Keystone authentication error (401):

JSON
{
  "error": {
    "code": 401,
    "title": "Unauthorized",
    "message": "The request you have made requires authentication."
  }
}

Heat request error (400, 404, and other 4xx):

JSON
{
  "code": 404,
  "title": "Not Found",
  "explanation": "The resource could not be found.",
  "error": {
    "type": "EntityNotFound",
    "traceback": null,
    "message": "The Stack (STACK_NAME) could not be found."
  }
}

A client should read the top-level error.code for Keystone errors and error.type for Heat errors. Observed error.type values and the status that accompanies them:

error.typeStatusCause
EntityNotFound404The named stack or resource does not exist
HTTPNotFound404The requested sub-resource (for example an event ID) does not exist
InvalidTemplateVersion400heat_template_version is not one of the supported values
Was this page helpful?