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

Санҷиши ҳаққоният

Kaliti API-ро ҳамчун рамзи доранда (bearer token) фиристед. Калит бояд дорои иҷозати sites.view бошад; калиди бидуни он бо хатои 403 рад карда мешавад, на 404.

Ин нуқтаи поёнӣ ягон рақами мушаххаси созмонро талаб намекунад. Калиди шумо аллакай созмонеро, ки ба он тааллуқ дорад, муайян мекунад ва ҷавоб ба он маҳдуд карда мешавад.

Санҷидан

Ҳар чизро дар қаavски кунҷӣ бо қиматҳои худ ва ҷойи нигоҳдорандаи калидро бо калима аз панели идоракунии худ иваз кунед.

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> }'

Воarid шудаед? Консоли API дар панели идоракунии шумо рақами мушаххаси ташкилоти воқеӣ ва калиди худро пур мекунад ва дархостро бар зидди API-и фаъол иҷро мекунад, то шумо посухи воқеиро бубинед. Ин нуқтаи ниҳоиро дар консоли API кушоед

Тафсилот

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.

Параметрҳо

Ҷисми дархост

Ҷавоб

Хатоҳое, ки ин нуқтаи ниҳоӣ метавонад баргардонад

401 · 403 · 404 · 422 · 429 · 503