POST /v1/ai/site-builds/{siteBuildId}/publications

Автентифікація

Надішліть ключ API як маркер носія (bearer token). Ключ повинен мати дозвіл hosting.deploy.manage; ключ без нього відхиляється з кодом 403, а не 404.

Цей кінцевий пункт не потребує ідентифікатора організації. Ваш ключ уже ідентифікує організацію, якій він належить, і відповідь обмежується її межами.

Спробувати

Замініть усе в кутових дужках власними значеннями, а заповнювач ключа — ключем із вашої панелі керування.

curl -X POST https://api.zinndigital.com/v1/ai/site-builds/{siteBuildId}/publications \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "site_id": <Uuid>, "disposition": <SiteMakerDisposition> }'

Увійшли в систему? Консоль API у вашій панелі керування автоматично підставляє ваш реальний ідентифікатор організації та ваш власний ключ, а також виконує запит до робочого API, щоб ви могли побачити справжню відповідь. Відкрийте цю кінцеву точку в консолі API

Деталі

Starts a durable publication and returns 202, not 201: the work has been accepted and is running. A 201 would say the site is published when the backup has not started, and a customer reads "created" as "done". disposition decides what happens to whatever is already on the destination: * add_to — every existing file is kept byte-for-byte and only new paths are written. A collision is renamed (about.html becomes about-new.html), never merged and never overwritten. revamp — markup, stylesheets and scripts are replaced; content, data files and robots.txt, sitemap.xml, .htaccess and ads.txt are kept. A file type we have never seen defaults to kept. replace — the whole tree becomes the draft. Destructive. A replace requires confirm_hostname to equal the site's own primary domain, typed. A boolean flag would be satisfied by any client that set it — including a retry and every future caller that copied the previous request body — so it would confirm that a field exists rather than that a human read the domain. Anything that would overwrite live files takes a full backup first and waits for it to finish. That includes a revamp that happens to overwrite real pages: the requirement is keyed on what the publication does, not on which word was chosen. A site whose hosting cannot produce a backup is refused rather than published, because we cannot make the change reversible there. One live publication per destination at a time; a second is refused with 409. Requires hosting.deploy.manage, and the target site is scoped by that same authority.

Параметри

Тіло запиту

Відповідь

Помилки, які може повертати ця кінцева точка

401 · 403 · 404 · 409 · 422 · 429