GET /v1/cdn/targets

אימות

שלחו מפתח API כאסימון נושא (bearer token). על המפתח לכלול את הרשאה sites.create; מפתח שאינו כולל אותה יידחה בסטטוס 403, ולא 404.

נקודת קצה זו אינה דורשת מזהה ארגון. המפתח שלך כבר מזהה את הארגון שאליו הוא שייך, והתגובה מוגבלת אליו בלבד.

נסה זאת

החלף כל דבר בסוגריים זוויתיים בערכים משלך, ואת מציין מיקום המפתח במפתח מלוח הבקרה שלך.

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

מחובר? קונסולת ה-API בלוח הבקרה שלך מזינה את מזהה הארגון האמיתי שלך ואת המפתח שלך, ומריצה את הבקשה מול ה-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