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

Նույնականացում

Ուղարկեք API բանալին որպես bearer token: Բանալին պետք է ունենա sites.view թույլտվությունը. առանց դրա բանալին մերժվում է 403, և ոչ թե 404 կարգավիճակով:

Այս վերջնակետը կազմակերպության ID չի ընդունում: Ձեր բանալին արդեն իսկ նույնականացնում է այն կազմակերպությունը, որին պատկանում է, և պատասխանը սահմանափակված է դրանով:

Փորձել

Փոխարինեք անկյունային փակագծերում գտնվող ցանկացած բան ձեր սեփական արժեքներով, և բանալու տեղապահը՝ ձեր վահանակի բանալիով:

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

Մուտք գործե՞լ եք: Ձեր վահանակի API վահանակը լրացնում է ձեր իրական կազմակերպության ID-ն և ձեր սեփական բանալին և գործարկում է հարցումը ուղիղ 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