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

ავტორიზაცია

API გასაღები გაგზავნეთ როგორც მატარებელი ტოკენი (bearer token). გასაღებს უნდა ჰქონდეს sites.view ნებართვა; ამის გარეშე გასაღები უარყოფილი იქნება 403 და არა 404 სტატუსით.

ეს ბოლო წერტილი არ იღებს ორგანიზაციის იდენტიფიკატორს. თქვენი გასაღები უკვე აიდენტიფიცირებს იმ ორგანიზაციას, რომელსაც ის ეკუთვნის, და პასუხი შემოფარგლულია მისით.

სცადეთ

შეSubstituted any value inside angle brackets with your own and the key placeholder with a key from your dashboard.

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

შესული ხართ? თქვენი სამართავ პანელში არსებული API კონსოლი ავტომატურად ამატებს თქვენი რეალური ორგანიზაციის ID-სა და საკუთარ გასაღებს და ატარებს მოთხოვნას ცოცხალ API-ს წინააღმდეგ, რათა იხილოთ რეალური პასუხი. გაAღით ეს ენდპოინტი 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