POST /v1/sites/{siteId}/retry-provisioning

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

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

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

Санҷидан

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

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/retry-provisioning \
  -H "Authorization: Bearer zdk_live_…"

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

Тафсилот

Re-runs provisioning for a site whose build failed or never started. The transition failed -> provisioning has always been legal and the status enum's own comment says "retry or delete" — this is the door. Idempotent, and pressing it twice is a success. A site that is already provisioning answers 202 with restarted: false rather than a 409: a customer pressing a button twice has not made an error. Three independent mechanisms make that safe — the workflow id is derived from the site id, the start policy is ALLOW_DUPLICATE_FAILED_ONLY so a completed provision can never be re-run, and the status transition locks and re-reads the row. ⛔ Nothing here calls Temporal (§2.9). The status change and a site.created event commit in one transaction and the existing consumer starts the workflow, so a Temporal outage cannot leave the row half-moved. A site that is active, deleting or deleted is a 422 — a retry re-runs the build, and those are past it. Requires sites.view and hosting.deploy.manage.

Параметрҳо

Ҷавоб

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

401 · 403 · 404 · 422 · 429