GET /v1/sites/deployable-plans

認証

ベアラー トークンとして API キーを送信します。このエンドポイントでは仕様に特定の権限が記載されていないため、キーに必要な最小限の権限を付与し、推測するのではなくレスポンスを確認してください。

試してみる

アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。

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