Version 2.4.0 of the customer API went live on 2026-07-02. It is a non-breaking release: everything your existing scripts and agents do keeps working. Errors now carry machine-readable codes, cancellations show your credit up front, and the MCP server gets friendlier for agents. The always-current reference lives at /user-api/docs/. Highlights below, grouped as fixes, additions, and documentation.

Fixes

• Asking about a VM that does not exist (or is not yours) now returns a clean 404 with error_code: not_found where it previously returned a server error.
• GET /vm/{id}/summary now includes a live runtime object (power state, lock, CPU and memory usage) — no second call needed to see whether a server is running. If the hypervisor read fails, runtime is null and the summary still returns.
• All timestamps are now true UTC. Some date fields (such as date_created and date_renews) were previously emitted five hours ahead; formats are unchanged.
• A newly created server's activity feed now shows its own provisioning tasks instead of coming back empty.
• Orders that cannot resolve an OS template are rejected up front with 422 and a list of the valid template values — likewise for configuration options that belong to a different package. No more half-failed orders from a typo.
• API responses now begin with { — the stray banner line some clients had to strip is gone.

Additions

• Stable error codes. Every error now carries error.error_code, a machine code your scripts can match on instead of parsing message text: not_found, invalid_token, vm_locked, insufficient_credit, upstream_failure, rate_limited. Transient conditions also carry error.retry_after_seconds, so a well-behaved client knows exactly how long to back off.
• Cancellation shows your credit. Cancel responses now include expected_refund and transaction_id — the pro-rated credit for unused prepaid time, computed by the same model the portal uses and issued as account credit. See Refunds and cancellations.
• Friendlier field names. Several responses dual-emit aliases (for example balances/credit on the balance endpoints, a singular service_id on order responses, and id/backup_id/snapshot_id on backup and snapshot items), and write bodies accept the aliases too. Existing field names all keep working.
• Small conveniences. Firewall rule action is case-insensitive on input; GET /ssh-key accepts ?service_id=; console sessions accept a ttl; confirmation challenges mirror the id flat at confirmation.confirmation_id; and an agent can exchange a single-use claim code for an API key at POST /agent-keys/claim.
• MCP improvements. Every tool result now carries structuredContent.result (the unwrapped payload, uniform for reads and writes); a listApiKeys tool lets a full-scope key list key metadata (creating and revoking keys still requires your password); older tool names keep working as aliases; and the server reports its spec version and tool count, so an agent can tell exactly what it is talking to.
• Zero-knowledge recovery key kinds. The zero-knowledge backup registration documents the full set of recovery key kinds — passphrase, 24-word recovery card, SSH ed25519, Nostr, Bitcoin wallet (BIP-85), and PGP. See Zero-knowledge backups: your recovery keys. You can now arm encryption to an SSH key in one click from your server's Backups tab — see turning it on.

Documentation

• The API reference now opens with a “What's new” section, documents the machine error-code registry with retry guidance, and publishes the exact cancellation refund formula — what gets credited, the minimum charge retained, and why an end-of-term cancellation credits zero.
• Two new knowledge base articles cover zero-knowledge backups: the practical recovery guide and the normative key derivation reference with test vectors.

Nothing in this release requires changes on your side. If you built workarounds for the fixed items — stripping a banner line, adding five hours to dates, calling /detail just for power state — you can remove them.