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

प्रमाणीकरण

एपिआई कुञ्जीलाई बियरर टोकन (bearer token) को रूपमा पठाउनुहोस्। कुञ्जीसँग sites.view अनुमति हुनुपर्छ; अनुमति नभएको कुञ्जीलाई 404 होइन, 403 मार्फत अस्वीकार गरिन्छ।

यो इन्डपोइन्टले कुनै संस्थाको आइडी लिँदैन। तपाईंको कुञ्जीले यस अन्तर्गत पर्ने संस्थालाई पहिल्यै पहिचान गर्छ, र प्रतिक्रिया त्यसैमा सीमित हुन्छ।

प्रयास गर्नुहोस्

कोणीय कोष्ठकभित्र भएका जुनसुकै कुरालाई आफ्नो मानहरूद्वारा बदल्नुहोस्, र मुख्य स्थानहोल्डरलाई तपाईंको ड्यासबोर्डको कुञ्जीद्वारा बदल्नुहोस्।

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

लगइन गर्नुभएको छ? तपाईंको ड्यासबोर्डमा रहेको 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