POST /v1/compute/servers/{serverId}/add-on

Xác thực

Gửi khóa API dưới dạng mã thông báo bearer. Khóa này phải có quyền sites.view; khóa không có quyền này sẽ bị từ chối với mã lỗi 403, không phải 404.

Endpoint này không nhận ID tổ chức. Khóa của bạn đã xác định tổ chức mà nó thuộc về và phản hồi được giới hạn trong phạm vi đó.

Dùng thử

Thay thế bất kỳ nội dung nào trong ngoعل (angle brackets) bằng giá trị của riêng bạn và trình giữ chỗ key bằng một key từ trang tổng quan của bạn.

curl -X POST https://api.zinndigital.com/v1/compute/servers/{serverId}/add-on \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "code": <string> }'

Đã đăng nhập? Bảng điều khiển API trong trang quản lý của bạn sẽ tự điền ID tổ chức thực tế và khóa của riêng bạn, sau đó chạy yêu cầu đối với API trực tiếp để bạn có thể xem phản hồi thực tế. Mở điểm cuối này trong bảng điều khiển API

Chi tiết

Requires `sites.view` and `billing.payment.manage`. ⛔⛔ **It was `billing.entitlement.manage` until 2026-08-17, which no customer role holds**, so the add-on designed to be turned on later could be turned on by nobody who owns a machine. The gate moved because the property behind it did: the add-on's price now joins the machine's subscription (priced into the cart line at order, moved from the next period when taken later), so this no longer spends Zinn®'s money and bills nobody. ⚖️ `billing.payment.manage` is the key the owner ruled for this class of control on 2026-08-17 (`docs/136` §2e) — `owner` and `billing`, and deliberately **not** `dev`: a developer creates sites, and does not commit the organisation to a recurring licence. ⛔ **A machine with no subscription is refused `422`** unless the caller also holds `billing.entitlement.manage`. Nothing would charge for the add-on there — that is the staff "on the house" path, and it stays deliberate rather than accidental. ⛔⛤ **AN ADD-ON WITH `applies_at` OF `running` OR `running_reboot` IS INSTALLED ON THE MACHINE AS IT STANDS, AND THE DATA ON IT IS NOT TOUCHED.** Until 2026-08-31 this endpoint refused every one of them with a sentence about rebuilding the disk. That sentence described a limitation of **cloud-init**, which runs only at create, and not of Plesk or CloudLinux — both of which ship installers whose documented purpose is converting a server that is already running. `docs/314` carries the vendor evidence. Such a request starts a Temporal workflow and answers `201` with `state` of `installing` (or `queued`, when a pooled licence is out of stock). The client polls `GET` for `install_step`. Plesk takes around fifteen minutes; CloudLinux restarts the machine once. ⛔⛔ **It requires `access` — one-time root credentials — and it is refused `422` without them.** This range hands SSH keys to the *customer* at build and the platform holds no key to any machine on it, so there is no standing credential to reach a running box with, and `docs/127` D4 chose deliberately never to create one. The credential is written to Vault under a path scoped to this one assignment, read only inside the install activities, kept out of the workflow history, and **deleted on every terminal outcome** — success, failure or refusal. ⛔ **A genuinely build-only add-on is still refused `422`** with a sentence naming the remedy. Nothing in the catalogue is build-only today; the refusal is kept for the day something is. ⛔ `503`, not `422`, when a pooled licence is out of stock **at order time**: the customer's next action is to try again, not to change their order. ⚖️ On a machine that is already running the same condition **queues** instead, by the owner's ruling of 2026-08-31 — the two paths differ because the moment differs, and at order time a refusal still reaches the customer before they have committed.

Tham số

Nội dung yêu cầu

Phản hồi

Các lỗi điểm cuối này có thể trả về

401 · 403 · 404 · 422 · 429 · 503