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

ማረጋገጫ

የAPI ቁልፉን እንደ bearer token ይላኩ። ቁልፉ የsites.view ፈቃድ ሊኖረው ይገባል፤ ይህ ፈቃድ የሌለው ቁልፍ በ404 ሳይሆን በ403 ውድቅ ይደረጋል።

ይህ ኤንድፖይ መክፈቻ (endpoint) የድርጅት መታወቂያ (organisation id) አይወስድም። የእርስዎ ቁልፍ (key) እሱ የሚመለከተውን ድርጅት አስቀድሞ ይለያል፣ እና ምላሹም ለዚሁ የተወሰነ ነው።

ሞክሩት

በቅንፍ ውስጥ ያለውን ማንኛውንም ነገር በራስዎ እሴቶች ይተኩ፣ እና ቁልፍ ቦታ ያዢውን ከዳሽቦርድዎ በመጣ ቁልፍ ይተኩ።

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

ገብተዋል? የመቆጣጠሪያ ማዕከልዎ ውስጥ ያለው የኤፒአይ ኮንሶል ትክክለኛውን የድርጅት መታወቂያዎን እና የራስዎን ቁልፍ ይሞላል፣ እና ትክክለኛውን ምላሽ ማየት እንዲችሉ ጥያቄውን በቀጥታ ከሚሰራው ኤፒአይ ጋር ያካሂደዋል። ይህን ኤንድፖይንት በ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