GET /v1/cdn/targets

認証

ベアラー トークンとして API キーを送信します。キーには sites.create 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。

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

試してみる

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

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

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

詳細

The CDN destinations a site you are about to create could be placed on: Zinn®'s own pool, and one row per CDN account you have connected. ⛔⛤ This exists because the create wizard asked a boolean. "Use my own CDN" is a checkbox, and a checkbox cannot name one of two accounts — so a customer with two Cloudflare accounts said "mine" and the platform chose which. The wizard also showed that checkbox only when a connected provider was literally cloudflare, so an account on Bunny or CDN77 had no control at all and no explanation for its absence. ⛔ Pass product_line. It is the one input that changes the answer: on a platform-managed line (Footprint-Free) creating straight onto your own account is refused — every site on one account can be linked to every other on it, which is what that line is sold to prevent — so each account comes back listed, unavailable, with reason: line_is_platform_managed. Listing it and saying why is the point: a customer who cannot find their account concludes the connection failed. ⭐ changes_nameservers is the field to render before the customer commits. A zone-owning CDN assigns nameservers per account, so choosing your own account means your registrar must be pointed at that account's pair. Advisory and read-only; the create itself re-checks everything. Requires sites.create.

パラメータ

返信

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

401 · 403 · 429