ai

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

Publish a draft to a destination, taking a backup first when it destroys.

Ҳамаи нуқтаҳои ниҳоии ai

Санҷиши ҳаққоният

Kaliti API-ро ҳамчун рамзи доранда (bearer token) фиристед. Калит бояд дорои иҷозати hosting.deploy.manage бошад; калиди бидуни он бо хатои 403 рад карда мешавад, на 404.

Ин нуқтаи поёнӣ ягон рақами мушаххаси созмонро талаб намекунад. Калиди шумо аллакай созмонеро, ки ба он тааллуқ дорад, муайян мекунад ва ҷавоб ба он маҳдуд карда мешавад.

Санҷидан

Ҳар чизро дар қаavски кунҷӣ бо қиматҳои худ ва ҷойи нигоҳдорандаи калидро бо калима аз панели идоракунии худ иваз кунед.

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> }'

Воarid шудаед? Консоли 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.

Параметрҳо

НомНамудТалаб карда мешавадИн чӣ аст
siteBuildId (path)UuidБале

Ҷисми дархост

НомНамудТалаб карда мешавадИн чӣ аст
site_idUuidБалеUUIDv7 identifier — sortable by creation time (docs/02 §8).
dispositionSiteMakerDispositionБалеWhat to do with what is already on the destination. `add_to` keeps every existing byte, `revamp` replaces presentation and keeps content, `replace` is destructive and requires a…
confirm_hostnamestringНеThe site's own primary domain, typed by a human. Required for `replace` and compared exactly (case and surrounding space are ignored). ⛔ Not a boolean: a flag is satisfied by an…
install_pluginsstring[]НеSlugs from the curated catalogue. Re-vetted server-side; anything else is dropped and counted. The client's list is a request, never an authority.
include_generated_pluginbooleanНеRegenerate and re-scan the custom plugin, and install it if it passes.

Ҷавоб

НомНамудТалаб карда мешавадИн чӣ аст
publicationSiteMakerPublicationБале

Хатоҳое, ки ин нуқтаи ниҳоӣ метавонад баргардонад

401 · 403 · 404 · 409 · 422 · 429