Huddle01 Cloud

API Changelog

A record of breaking changes, deprecations, and new additions to the Huddle01 Cloud API.

All notable changes to the Cloud API are documented here. Dates follow YYYY-MM-DD format.


2026-05-29

New features

POST /instances — cloud-init user data and password login

Create instance requests now accept user_data and admin_pass.

FieldStatusDescription
user_dataNewCloud-init user-data applied on first boot.
admin_passNewInitial instance password. When provided, password-based SSH login settings are merged into generated cloud-init.

This also fixes the public POST /instances create path so these fields are preserved when the API translates the request into the internal VM create request. Previously, admin_pass could be accepted by clients but omitted from the generated cloud-init.

Example request:

curl -X POST "https://cloud.huddleapis.com/api/v1/instances" \
  -H "x-api-key: $HUDDLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "password-vm",
    "flavor_name": "anton-2",
    "image_name": "ubuntu-22.04",
    "boot_disk_size": 30,
    "key_name": ["my-key"],
    "sg_names": ["allow-ssh"],
    "admin_pass": "replace-with-a-strong-password",
    "user_data": "#cloud-config\npackage_update: true\n"
  }'

Security note

admin_pass and user_data can contain secrets. Store them carefully in clients, Terraform state, CI logs, and request traces.


2026-05-27

New features

POST /infra/v1/agents/{id}/reset — optional LLM provider and model selection

Reset requests now accept optional llm_provider and llm_key fields. When omitted, the redeployed agent defaults to HUDL AI (hudl) with the standard HUDL default model (hudl/minimax-m2.7), matching the agent deploy UI. For bring-your-own-key providers (openrouter, openai, google, anthropic), llm_key is required and the provider's standard default model is used unless llm_model is explicitly provided. Flavor, storage size, and billing linkage behavior are unchanged.

2026-05-19

New features

POST /infra/v1/agents/coupons/verify — verify agent promotion codes

Restores coupon verification before agent checkout. The endpoint checks Stripe for an active promotion code matching coupon_code and returns valid, coupon_code, and message.

2026-04-22

Breaking changes

GET /instances · GET /instances/{id}flavor_id field renamed to flavor

The instance object previously returned flavor_id (an opaque OpenStack UUID). It now returns flavor — the human-readable flavor name (e.g. "anton-2").

 {
   "id": "abc123",
   "name": "my-vm",
-  "flavor_id": "c1f52b0a-4a3d-4b2e-9d1e-8f3a2c6e7d4f",
+  "flavor": "anton-2",
   "vcpus": 2,
   "ram": 4096,
   ...
 }

Migration: Update any code that reads instance.flavor_id to read instance.flavor instead.


New features

POST /instances — accept flavor and image by name

The create endpoint now accepts human-readable names in addition to raw OpenStack IDs. Using names is the recommended approach going forward.

FieldStatusDescription
flavor_nameNew (preferred)Flavor name, e.g. "anton-2", "anton-4"
image_nameNew (preferred)Image name, e.g. "ubuntu-22.04"
flavor_idDeprecatedRaw OpenStack flavor UUID — still accepted, see deprecations below
image_idDeprecatedRaw OpenStack image UUID — still accepted, see deprecations below

At least one of flavor_name / flavor_id is required, and at least one of image_name / image_id is required. If both are provided, the name field takes priority.

Example request using names:

curl -X POST "https://cloud.huddleapis.com/api/v1/instances" \
  -H "x-api-key: $HUDDLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-vm",
    "flavor_name": "anton-2",
    "image_name": "ubuntu-22.04",
    "boot_disk_size": 30,
    "key_name": ["my-key"],
    "sg_names": ["default"],
    "region": "eu2"
  }'

POST /instancesdeprecation_notices in response

When a deprecated field (flavor_id or image_id) is used in a create request, the response now includes a deprecation_notices array with migration guidance. The field is omitted when no deprecated fields are used.

{
  "id": "abc123",
  "name": "my-vm",
  ...
  "deprecation_notices": [
    "The 'flavor_id' field is deprecated and will be removed in a future version. Please use 'flavor_name' instead (e.g. \"anton-2\")."
  ]
}

GET /instances · GET /instances/{id} — private IPs included in networks.v4

The networks.v4 array now contains both private ("fixed") and public ("floating") IPv4 addresses. Previously only floating (public) IPs were returned.

Each entry has a type field ("fixed" or "floating") to distinguish them:

{
  "networks": {
    "v4": [
      { "ip_address": "10.10.1.70",    "type": "fixed" },
      { "ip_address": "148.113.4.91",  "type": "floating" }
    ],
    "v6": []
  }
}

Check your IP filtering logic

If your code accesses networks.v4[0] to get the public IP, it may now get the private IP instead. Filter by type === "floating" to reliably select the public address.


Deprecations

The following fields are deprecated and will be removed in a future version. They continue to work today but emit a deprecation_notices entry in the response.

Deprecated fieldReplacementEndpoint
flavor_id (request)flavor_namePOST /instances
image_id (request)image_namePOST /instances