GET /v1/hosting/locations

認証

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

このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。

試してみる

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

curl -X GET https://api.zinndigital.com/v1/hosting/locations \
  -H "Authorization: Bearer zdk_live_…"

ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く

詳細

Every data centre a new site may be placed in, across both estates (docs/370): the locations this platform has activated for the managed hosting range (docs/62 §3.5), plus the regions of our own fleet that currently have a worker able to take the site. Activating a managed-range location is a reseller-level purchase — activate once, host unlimited sites in it — and a fleet region is available whenever a box there is active, accepting deploys and not full. The answer carries no tenant scope; it is authenticated only because it describes our estate rather than being marketing copy. An empty list is a real answer, not an error: nothing is activated and no fleet worker can take the site, a managed-range location could not be pinned with the configuration present, or the line is one we do not offer a choice on. The client must then hide the picker and let the default placement apply — it must never substitute a list of its own, because creating a site in a location we have not activated is refused by the vendor after the customer has chosen, and a fleet region with no box behind it fails in placement for the same reason. code is the placement identifier (lhr, nbg1) and the suffix of the i18n key the client renders; country is ISO-3166 alpha-2 for a decorative flag. There is deliberately no display name — location names are translated like every other user-facing string, and a flag is never the accessible name.

パラメータ

返信

このエンドポイントが返すエラー

401 · 429