ai

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

Put an AI-built site live on one of the organization's sites.

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

Ҳамаи ҳуҷҷатҳои таҳиякунандагон

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

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

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

Санҷидан

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

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

Воarid шудаед? Консоли API дар панели идоракунии шумо рақами мушаххаси ташкилоти воқеӣ ва калиди худро пур мекунад ва дархостро бар зидди API-и фаъол иҷро мекунад, то шумо посухи воқеиро бубинед. Ин нуқтаи ниҳоиро дар консоли API кушоед

Тафсилот

Deploys the draft's files to the named site's edge host — Cloudflare Pages, Netlify, GitHub Pages, GitLab Pages, Vercel or AWS Amplify — and optionally pushes them to the organization's git provider as well. Idempotent on the build: a retried publish republishes the same draft rather than stacking a second deployment, and produces neither a duplicate repository nor an empty commit. A site on our own fleet is published through its own repository instead, because a fleet document root accepts bytes from exactly one place: a git checkout over SSH. The customer's connected GitHub or GitLab repository is therefore a prerequisite there rather than the optional extra it is on an edge host — a site without one is refused with fleet_needs_repo, naming the missing connection. That path can also finish held rather than published, which no edge publish does. A fleet document root holding files we did not put there is left untouched and hold_reason says so: overwriting it would destroy the customer's own work silently. The generated files are safe in the repository and the customer chooses which version wins on the site's sync screen. A held response is a successful refusal — do not retry it automatically. A site that is neither on our fleet nor on a managed edge host is refused with that provider's own reason. A site on a resold package is refused because its vendor publishes it, not us. Requires hosting.deploy.manage — a separate and stronger authority than reading a draft, so somebody who may look at one cannot put it in front of the public. The target site is scoped by that same authority, so naming a site the caller may only view is a 404.

Параметрҳо

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

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

НомНамудТалаб карда мешавадИн чӣ аст
site_idUuidБалеThe site to publish onto. It must already be on a managed edge host; a site on a resold package is refused with the provider's own reason, not a generic failure.
connect_repobooleanНеAlso put the files in the organization's connected git provider. Defaults to false: creating a repository on somebody's account is a named, permanent artefact on an account we…
repo_ownerstringНеWhich account to create the repository under. Required for a new repository and ignored when the site already has one. ⛔ Never inferred: one token reaches every account it was…

Ҷавоб

НомНамудТалаб карда мешавадИн чӣ аст
buildSiteBuildБалеOne "describe a site and we build it" run. files is present on the detail and create responses and absent from the list, deliberately: a generated tree can be a hundred…
trialSiteBuilderTrialНеThe one-time free allowance for the AI site builder. One grant per organization, for ever — not monthly, and not per site. granted is true because the credit was actually…

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

401 · 403 · 404 · 422 · 429