GET /v1/sites/deployable-plans

身份验证

请将 API 密钥作为 bearer 令牌发送。此端点在规范中未指明具体的权限，因此请为您的密钥赋予所需的最小权限，并通过检查响应来确认，而不是盲目假设。

免费试用

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

curl -X GET https://api.zinndigital.com/v1/sites/deployable-plans \
  -H "Authorization: Bearer zdk_live_…"

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

详细信息

Answers "what plan do I already have to add sites to" — one entry per plan the organization (or an ancestor, under hierarchical tenancy) already holds, with its free slots and the product lines it can actually take a site on. It exists because the create wizard opened on a flat list of every active product line with no indication which of them the customer owned or could use, so the common case — I have capacity, I want another site — was buried in a catalogue. Deploying into capacity you already own and buying more capacity are two different jobs, and this endpoint is the first of them. ⛔ Every entry resolves through the same function POST /v1/sites enforces, so a card reading "193 free" and a create answering SITE_QUOTA_EXCEEDED cannot disagree. It is advisory in exactly the way /v1/sites/capacity is: no lock is taken, so a concurrent create may still win the last slot. ⛔ Lines that no purchasable plan grants a site slot on are never returned — a managed database has no document root and a Boards plan is not hosting, so offering either as somewhere to create a website is a dead end. The set is derived from the catalogue, so a line an operator seeds tomorrow is classified correctly without a deploy. An empty data means the organization can deploy nowhere and must buy capacity first. The figures are gated exactly as /v1/sites/capacity gates them.

参数

响应

此端点可能返回的错误

401 · 403