hosting

POST `/v1/sites/{siteId}/site-blueprint-deploy`

Replace a site's content with a blueprint's.

احراز هویت

یک کلید API را به عنوان یک توکن برbearer ارسال کنید. این نقطه پایانی مجوز خاصی را در مشخصات خود ذکر نمی‌کند، بنابراین به جای فرض کردن، حداقل نیازهای کلید خود را بدهید و پاسخ را بررسی کنید.

این نقطه پایانی هیچ شناسه سازمانی را دریافت نمی‌کند. کلید شما در حال حاضر سازمان مربوطه را مشخص می‌کند و پاسخ در همان محدوده ارائه می‌شود.

امتحان کنید

هر چیزی را که داخل براکت‌های زاویه‌دار قرار دارد با مقادیر خودتان جایگزین کنید، و نگهدارنده کلید را با کلیدی از داشبورد خود جایگزین نمایید.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/site-blueprint-deploy \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "blueprint_id": <Uuid> }'

وارد شده‌اید؟ کنسول API در داشبورد شما شناسه سازمان واقعی و کلید خودتان را پر می‌کند و درخواست را روی API زنده اجرا می‌کند تا بتوانید پاسخ واقعی را ببینید. این نقطه پایانی را در کنسول API باز کنید

جزئیات

⛔ Destructive. This overwrites the site's live database and files with the contents of the named blueprint, then rewrites the restored content's stored web addresses to this site's domain (a WordPress database names its own URLs, so without that step the new site would redirect its visitors to the old one). Its own path on the site, beside backups/restore, rather than a verb on the blueprint — the destruction happens here, so it is gated on hosting.backup.manage and cannot be reached by varying the body of anything gentler. ⛔ A blueprint captured from a different stack is refused with a 422 (stack_mismatch) — WordPress can only be deployed onto WordPress. So is one from a different hosting platform (platform_mismatch), whose archive our adapter cannot restore here. A blueprint belonging to a different account is refused with org_mismatch, even when your token can reach both: hierarchical tenancy means a reseller's key spans every client organisation, and a blueprint is that site's whole database — it never crosses between accounts. A blueprint that is still being captured is blueprint_not_ready. A deploy already in flight on this site is a 409. The refusal is a machine code, carried in error.details[0].code, so a client can render it in the customer's own language; error.message is the English equivalent for a caller with no catalogue. ⛔ Read the code from details, not from error.code — that is the generic UNPROCESSABLE_ENTITY for every 422 this API produces.

پارامترها

نام	نوع	الزامی	چیست
`siteId (path)`	`Uuid`	بله	Site ID (UUIDv7).
`Idempotency-Key (header)`	`string`	خیر	Client-generated key that makes an unsafe request replay-safe: the server stores the first response and returns it verbatim for repeats.

بدنه درخواست

نام	نوع	الزامی	چیست
`blueprint_id`	`Uuid`	بله	The SITE blueprint to deploy. ⛔ Always named explicitly — never "the latest". This overwrites a live site.

پاسخ

نام	نوع	الزامی	چیست
`id`	`Uuid`	بله	UUIDv7 identifier — sortable by creation time (docs/02 §8).
`blueprint_id`	`Uuid`	بله	UUIDv7 identifier — sortable by creation time (docs/02 §8).
`site_id`	`Uuid`	بله	UUIDv7 identifier — sortable by creation time (docs/02 §8).
`status`	`SiteBlueprintDeployStatus`	بله	⭐ `waiting` is a real state and not a synonym for `pending`. A deploy started from the create form cannot restore anything until the new site has finished provisioning, which…
`message`	`string`	خیر	Why it failed, or — after a successful restore whose URL rewrite did not take — what still needs attention. Rendered to the customer verbatim.
`started_at`	`object`	خیر	—
`finished_at`	`object`	خیر	—
`created_at`	`string`	بله	—

خطاهایی که این نقطه پایانی می‌تواند برگرداند

401 · 403 · 404 · 409 · 422 · 429 · 503

POST /v1/sites/{siteId}/site-blueprint-deploy