ai
POST /v1/ai/site-builds/{siteBuildId}/publications
Publish a draft to a destination, taking a backup first when it destroys.
ప్రమాణీకరణ
బీయర్ టోకెన్గా API కీని పంపండి. కీ తప్పనిసరిగా hosting.deploy.manage అనుమతిని కలిగి ఉండాలి; అది లేని కీని 404 కాకుండా 403తో తిరస్కరిస్తారు.
ఈ ఎండ్పాయింట్ ఎలాంటి సంస్థ ఐడీని తీసుకోదు. మీ కీ ఇప్పటికే అది ఏ సంస్థకు చెందుతుందో గుర్తిస్తుంది మరియు ప్రతిస్పందన దానికే పరిమితం చేయబడుతుంది.
ప్రయత్నించండి
కోణీయ బ్రాకెట్లలో ఉన్న దేన్నైనా మీ స్వంత విలువలతో భర్తీ చేయండి, మరియు కీ ప్లేస్హోల్డర్ను మీ డాష్బోర్డ్ నుండి తీసుకున్న కీతో భర్తీ చేయండి.
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 కాన్సోల్ మీ అసలైన సంస్థ ID మరియు మీ స్వంత కీని నింపుతుంది, అలాగే మీరు అసలైన ప్రతిస్పందనను చూడటానికి లైవ్ 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_id | Uuid | అవును | UUIDv7 identifier — sortable by creation time (docs/02 §8). |
disposition | SiteMakerDisposition | అవును | 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_hostname | string | కాదు | 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_plugins | string[] | కాదు | 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_plugin | boolean | కాదు | Regenerate and re-scan the custom plugin, and install it if it passes. |
స్పందన
| పేరు | రకం | కావలసినది | ఇది ఏమిటి |
|---|---|---|---|
publication | SiteMakerPublication | అవును | — |
ఈ ఎండ్పాయింట్ తిరిగి ఇవ్వగల లోపాలు
401 · 403 · 404 · 409 · 422 · 429