hosting

GET /v1/sites/{siteId}/protection/file-permissions

Run the vendor's file-permission check on a site.

すべての hosting エンドポイント

認証

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

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

試してみる

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

curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/protection/file-permissions \
  -H "Authorization: Bearer zdk_live_…"

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

詳細

⛔ **This `GET` RUNS the scan — it is not a cached read.** The vendor's read *is* the check, so it walks the site's filesystem. It is an explicit *"check my permissions"* action and must never fire on mount or on window focus. `check_id` is the handle the fix needs, and it is **nullable**: null means the vendor gave us no handle, so `actionable` is false and there is nothing to apply. `recommended` on each failure is nullable for the same reason — the platform sometimes names a file without naming a mode, and a guessed `644` would be applied to the customer's file. `404` for a site with no vendor hosting package. Requires `sites.view`.

パラメータ

名前タイプ必須これがその内容です
siteId (path)UuidはいSite ID (UUIDv7).

返信

名前タイプ必須これがその内容です
check_idintegerはいThe vendor's handle for this check. **Null** when the vendor gave us none, in which case there is nothing to apply and `actionable` is false. ⛔ A client never sends it back: `fi…
public_html_wrongbooleanはいWhether the document root's own mode is wrong.
root_wrongbooleanはいWhether the package root's own mode is wrong.
failuresSitePermissionFailure[]はいThe individual files the check flagged.
actionablebooleanはいWhether *Fix these* can do anything: a live check handle **and** something to fix. Its own field so the button is not offered against a report that can only be refused.

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

401 · 403 · 404 · 429 · 503