ai
POST /v1/ai/site-builds/{siteBuildId}/preview
What publishing this draft would do to that site. Changes nothing.
認証
ベアラー トークンとして API キーを送信します。キーには hosting.deploy.manage 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。
このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。
試してみる
アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。
curl -X POST https://api.zinndigital.com/v1/ai/site-builds/{siteBuildId}/preview \
-H "Authorization: Bearer zdk_live_…" \
-H "Content-Type: application/json" \
-d '{ "site_id": <Uuid>, "disposition": <SiteMakerDisposition> }'ログインしていますか?ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く
詳細
Answers "what happens if the site is already there" before anything happens: which existing files are kept, which are added, which would be **overwritten**, and which generated files would be renamed to avoid a collision. This runs the same guard the publication itself runs, not a second description of it. A preview computed by different code is a promise the real path never made, and it would be wrong in exactly the cases that matter. The preview does **not** require the typed confirmation that a `replace` needs. A customer has to be able to see what would be destroyed before deciding to confirm it; demanding the confirmation in order to show the consequence is the wrong way round. Requires `hosting.deploy.manage`.
パラメータ
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
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… |
返信
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
preview | SiteMakerPreview | はい | — |
このエンドポイントが返すエラー
401 · 403 · 404 · 422 · 429