Skip to content

Verda API changes

For full API documentation go to Verda API docs

2026-10-07 Automatic top-ups in the audit log

A top-up charged automatically by auto top-up is now reported as an auto_top_up event instead of a topup one, so it can be told apart from a top-up you started yourself. This covers the charge being created, completed and canceled — com.verda.api.cloud.auto_top_up.create.v1, .complete.v1 and .cancel.v1.

Filtering by object_type=topup therefore no longer returns automatic charges; use auto_top_up for those. Events recorded before this change have been relabelled the same way, so the audit log reads consistently for past and future charges. Top-ups you started yourself are unaffected.

2026-09-25 Inference model prices in your billing currency

GET /v1/inference/models and GET /v1/inference/models/{code} now quote pricing and service_tier_pricing in the currency your account is billed in. Previously prices were always in USD.

Each service tier in service_tier_pricing is quoted at its own rate, and a service tier without prices of its own is left out.

2026-09-24 Managed instance groups

Managed instance groups provide reusable placement and template defaults for related instances. Use the /v1/instance-groups endpoints to manage groups. POST /v1/instances now accepts an optional instance_group_id; group instances inherit the group's instance type, image and location defaults.

2026-09-23 Deployment system logs

System logs of serverless container and job deployments are available through the public API. System logs are platform events about a deployment, such as scheduling failures, image pull errors and failed health checks.

Filter the events by reason, involved_object and search_text, and select the time range with since, start and end. Repeated events are grouped into one entry, with the number of grouped records in count.

2026-09-21 SSH key creator attribution

SSH key responses now include the additive nullable UUID field created_by_user_id, identifying the user who added that SSH key record to the project. Historical records without a matching creation event return null.

2026-09-21 HDD storage is being decommissioned

HDD storage is being decommissioned. Creating and resizing HDD volumes is no longer supported, and these requests now receive an HTTP 400 Bad Request response.

Existing HDD volumes keep working. You can still list, attach, detach, rename, restore and delete them, and you can clone one to NVMe to move off HDD.

To migrate an existing HDD volume, first detach it, or shut down the instance it is attached to — cloning requires the source to be detached, or its instance to be offline. Then clone it with action: "clone" and type: "NVMe". Once the clone reaches the detached status, delete the HDD source.

2026-09-16 Inference model service tiers

GET /v1/inference/models and GET /v1/inference/models/{code} now return service_tiers (the service tiers a model supports, similar to OpenAI's service_tier), service_tier_pricing (a price breakdown per tier), and endpoint_model (the id to send as model in an inference request).

endpoint_model is always present, and is usually the same as code. Send it as-is; there is no case where you have to fall back to another field.

2026-09-15 New image categories

GET /v1/images and GET /v1/images/cluster can now return confidentialComputing and docker in the category field, for confidential computing and Docker images.

2026-09-14 Container deployment templates

Curated model templates for serverless containers are available through the public API. A template pins an open model from Hugging Face to a serving engine and a tested configuration, so one request creates a working inference deployment.

2026-09-14 Deployment logs

Replica logs of serverless container and job deployments are available through the public API. Replica logs are the output that your containers write.

Filter the log lines by container_name, pod and search_text, and select the time range with since, start and end. The default time range is the last 15 minutes, and a time range cannot be longer than 7 days.

2026-09-11 Resource tags

Instances, clusters, and volumes now support key-value tags. Use tags to organize resources and filter the instance list.

  • Add tags while provisioning a new instance, cluster, or volume with the tags request property. New volumes included in an instance deployment can also have their own tags.
  • Add or remove tags from existing resources:
  • Tags are reusable within a project: the same key-value pair receives the same tag id wherever it is applied.
  • Filter instances with GET /v1/instances?tag=key or GET /v1/instances?tag=key=value. Repeat tag to require multiple tags.

Each resource can have up to 10 tags. Tag keys are normalized to lowercase; omit value to create a freeform tag.

2026-07-30 Audit log

The project audit log is now available in the console and through the API. It records who did what in a project, when, and from where, using the CloudEvents 1.0 JSON format.

Both endpoints are limited to the project owner and members with the admin role, and cover the last 90 days. Filter with object_type, action, start_date, and end_date. Read the audit log documentation.

Query parameters

  • object_type=compute: one object type, for example compute, volume, ssh_key, user.
  • action=delete: one action, for example create, delete, login.
  • start_date=2026-07-01T00:00:00.000Z: events at or after this timestamp, at most 90 days ago.
  • end_date=2026-07-31T00:00:00.000Z: events at or before this timestamp.
  • page_size=100: events per page, 1 to 100, default 20.
  • cursor=log_02yTr8Kc11BspqLM40XZQV: continue from the cursor of the previous response.

Example request:

GET /v1/audit/log?object_type=compute&action=delete&page_size=100

Example response:

{
  "data": [
    {
      "specversion": "1.0",
      "id": "log_033FNaNcc0AtphhH71DLBW",
      "source": "https://api.verda.com/project/7c9e6a41-2f8b-4d3e-9a15-0b6c4d2e8f37",
      "subject": "7bdb4161-c7d2-478c-9850-05719adc8381",
      "type": "com.verda.api.cloud.compute.delete.v1",
      "time": "2026-07-28T14:15:52.872Z",
      "data": {
        "contract": "PAY_AS_YOU_GO",
        "hostname": "tiny-tree-unfolds-fin-01",
        "instance_type": "CPU.4V.16G",
        "location_code": "FIN-01",
        "discontinue_reason": "by_user_action",
        "request_ip": "203.0.113.10",
        "request_origin": "console-11.67.0",
        "actor_id": "5bbb59cb-fced-44a4-85c6-5005e7480a8f",
        "compute": {
          "id": "7bdb4161-c7d2-478c-9850-05719adc8381",
          "hostname": "tiny-tree-unfolds-fin-01",
          "instance_type": "CPU.4V.16G",
          "ip": "192.0.2.15",
          "os_volume_id": "2b7d0e2e-fc8d-4e9c-8b89-6117a4d8d941",
          "location_code": "FIN-01",
          "is_cluster": false
        }
      }
    }
  ],
  "cursor": "log_02yTr8Kc11BspqLM40XZQV"
}

The CloudEvents envelope fields are stable. Field names inside data may still change while event coverage grows.

2026-06-12 Startup script list sorting

GET /v1/scripts is now sorted by creation date descending by default, so the most recently created scripts appear first and land on the first page. Previously the list was sorted ascending, which pushed newly created scripts onto the last page once pagination was in effect.

You can control the order with the optional orderBy and orderDirection query parameters.

Query parameters

  • orderBy=created_at — field to sort by. The only supported value is created_at, the script's creation timestamp from the response payload (also the default).
  • orderDirection=desc — sort direction, either asc or desc. Defaults to desc.

To restore the previous behavior (oldest first), request ascending order explicitly:

GET /v1/scripts?orderBy=created_at&orderDirection=asc

Example response:

[
  {
    "id": "9f3c1e2a-1b7d-4a4e-9c2f-8d5b6e7a0c11",
    "name": "Older startup script",
    "created_at": "2026-05-01T08:15:00Z"
  },
  {
    "id": "2b1af58-7537-4edb-ba81-82cee082c5e9",
    "name": "My startup script",
    "created_at": "2026-06-12T10:30:00Z"
  }
]

2026-06-09 SSH key fingerprint

The SSH keys endpoints now return a fingerprint field — the public key fingerprint as colon-separated hex. This is useful for checking whether the same key already exists or for matching a key against a local copy. The fingerprint is computed from the stored public key, so no extra request is needed.

Example response:

[
  {
    "id": "39479972-f06d-4a94-8027-75a0b42dcf6b",
    "name": "my-laptop",
    "key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAXy2Jl8/DqhHm9akSXVyRx3Zh5W4SzncepC2mKZEeDC [email protected]",
    "fingerprint": "9b:11:74:af:5c:04:48:31:40:ef:b5:ef:e3:dc:33:81"
  }
]

2026-03-30 Startup script quota and pagination

The number of startup scripts allowed per user per project is now limited by a quota with a default of 100 scripts and a hard maximum of 10000.

GET /v1/scripts now supports pagination via the page and pageSize query parameters. For backward compatibility, the response payload shape is unchanged and pagination metadata is returned in headers instead. See the Pagination section for details.

Query parameters

  • page=1
  • pageSize=10 (can be extended to a maximum of 100 records per page)

When pagination is available, the response includes these headers:

  • X-Page: 1 - current page number
  • X-Page-Size: 100 - current page size
  • X-Total-Count: 10000 - total number of matching items

Example request:

GET /v1/scripts?page=1&pageSize=100

Example response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 11111
X-Page: 1
X-Page-Size: 100
X-Total-Count: 10000

[{ "id": "2b1af58-7537-4edb-ba81-82cee082c5e9", "name": "My startup script" }]

2026-03-23 Property location_code is now required

The location_code property is now required in the request body when creating instances, clusters, or volumes via the Public API. Requests that omit it will receive an HTTP 400 Bad Request response instead of silently defaulting to FIN-01. This brings the API in line with the SDK, where specifying a region has always been mandatory.

Breakdown of API changes

Description Endpoint Schema change
Deploy instance POST /v1/instances { /* required */ location_code: string, ... }
Deploy cluster POST /v1/clusters { /* required */ location_code: string, ... }
Create block volume or SFS POST /v1/volumes { /* required */ location_code: string, ... }

2026-03-20 Scope-based access control for API tokens

API tokens created via the OAuth 2.0 Client Credentials flow are now issued with the scope cloud-api-v1 and restricted to documented Public API endpoints only. Previously, these tokens could access internal endpoints not intended for external use. If you are using API tokens for any undocumented endpoints, those requests will now return 403 Forbidden with "Insufficient scope". Only the endpoints listed in this API documentation are accessible with API tokens.

2026-03-20 Long term periods endpoints

Endpoint GET /v1/long-term/periods is now deprecated. Use the dedicated endpoints instead:

Improved OpenAPI documentation for all long term period endpoints with detailed property descriptions and examples.

2026-03-19 OpenAPI spec auth fix

Fixed the OpenAPI specification incorrectly requiring bearer authentication on public endpoints (/v1/instance-types, /v1/cluster-types, /v1/container-types, /v1/long-term/periods/*). These endpoints are publicly accessible and no longer show an authentication requirement in the spec.

2026-03-16 Volume response improvements

GET /v1/volumes/{id} now includes is_permanently_deleted and deleted_at fields when the volume is in deleted status. These fields are omitted for active volumes. The OpenAPI schema for this endpoint now uses oneOf to distinguish between the active-volume and deleted-volume response shapes.

2026-03-12 Improved instance action and volume deletion responses

Bulk instance actions (PUT /v1/instances) now return structured per-action results. Each result includes the instance id, a status (success or error), and an error message when applicable. When all actions succeed the response is 202 Accepted; when some fail, you receive a 207 Multi-Status with individual outcomes. A single-instance action that is already in the requested state now returns 204 No Content instead of an error.

Volume deletion (DELETE /v1/volumes/{id}) now returns 204 No Content when the volume is already deleted, making the operation idempotent.

OpenAPI schema fields that accept both a single UUID string and an array of UUIDs (id, ssh_key_ids, volume_ids) are now documented with oneOf for accurate client generation.

2026-03-11 API rate limits

Introduced rate limits to our Public API to ensure the stability of our API and platform for everyone. Rate limits are restrictions our API enforces on how frequently a user or client can make requests to our services within a given timeframe.

Please take a look at our API documentation section "Rate limits".

2026-02-03 Spot instance volume policy

When creating a spot instance, it is now possible to specify a removal policy for the OS volume and any additional volumes created alongside it. Use the on_spot_discontinue field:

POST /v1/instances

POST v1/instances
{
  "instance_type": "CPU.4V.16G",
  "image": "ubuntu-24.04",
  "ssh_key_ids": ["442e6a59-26c2-4cea-a619-39762c0d2385"],
  "hostname": "test-instance",
  "location_code": "FIN-03",
  "is_spot": true,
  "os_volume": {
    "name": "test-instance-os-volume",
    "size": 55,
    // If "delete_permanently", the volume will be deleted when the spot instance is discontinued
    "on_spot_discontinue": "keep_detached" | "move_to_trash" | "delete_permanently"
  }
}

2026-02-03 Delete volumes permanently when deleting an instance

When deleting an instance, you can now specify whether its volumes should be moved to deleted storage (default) or deleted permanently:

PUT /v1/instances

PUT v1/instances
{
  "action": "delete",
  "id": "442e6a59-26c2-4cea-a619-39762c0d2385",
  "volume_ids": ["5e9e63a9-fc3b-427b-b259-0c77dce61090"],
  // Will delete the instance and volumes permanently
  "delete_permanently": true
}