GET /v1/ai/site-builds/targets

身份验证

请将 API 密钥作为 bearer 令牌发送。该密钥必须具有 hosting.deploy.manage 权限；缺少该权限的密钥将被拒绝并返回 403 状态码，而非 404。

此端点不需要组织 ID。您的密钥已用于识别其所属的组织，且响应范围也仅限于该组织。

免费试用

将尖括号中的内容替换为您自己的值，并将键占位符替换为您仪表板中的一个键。

curl -X GET https://api.zinndigital.com/v1/ai/site-builds/targets \
  -H "Authorization: Bearer zdk_live_…"

已登录？您仪表板中的 API 控制台会自动填入您真实的组织 ID 和您自己的密钥，并针对实时 API 运行请求，以便您查看实际的响应。 在 API 控制台中打开此端点

详细信息

Lists every site the caller may deploy to, and — the part that did not exist before — **what is already there**. Publishing used to take a site id with no way to discover which ids were valid, and no way to learn that a destination had a live business on it. `occupancy` is the field to read, never `known_files`: * `empty` — nothing is deployed. Publishing here destroys nothing. * `ours` — we published the current contents ourselves, from an earlier draft. * `occupied` — something is there and we can read it, because the site has a connected repository. * `unknown` — something may be there and we **cannot** read it. This is deliberately not reported as `empty`: an empty destination is precisely the one where overwriting is safe, so the two must never collapse. A destination we cannot read offers `replace` only, and the customer is told to connect a repository if they want to add to it instead. `allowed_dispositions` is advisory — the screen uses it to decide which buttons to show, and the engine re-derives it when a publication is started. A client that offers a disposition this list omits is refused with `disposition_not_available`. Requires `hosting.deploy.manage`, even though this only reads: the list is "places you may publish to", and offering a destination the caller cannot use both answers the wrong question and discloses sites they may only view.

参数

响应

此端点可能返回的错误

401 · 403 · 429