GET /v1/sites/{siteId}/wordpress/update-policy

身份验证

请将 API 密钥作为 bearer 令牌发送。该密钥必须具有 sites.view 权限；缺少该权限的密钥将被拒绝并返回 403 状态码，而非 404。

此端点不需要组织 ID。您的密钥已用于识别其所属的组织，且响应范围也仅限于该组织。

免费试用

将尖括号中的内容替换为您自己的值，并将键占位符替换为您仪表板中的一个键。

curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/wordpress/update-policy \
  -H "Authorization: Bearer zdk_live_…"

已登录？您仪表板中的 API 控制台会自动填入您真实的组织 ID 和您自己的密钥，并针对实时 API 运行请求，以便您查看实际的响应。 在 API 控制台中打开此端点

详细信息

Returns three things that must never be collapsed into one: the **policy** an operator stored, what the site is **actually** configured to do, and the **drift** between them. ⛔ A screen showing only the stored policy cannot tell a customer that the policy was never applied — which is the whole point. A decision is applied when a row changes, and the row that decides whether a WordPress updates itself lives on that WordPress, not in this platform's database. A customer can change any of it from wp-admin, a plugin can change it on activation, and a restored backup carries the old settings back. ⛔ `observed_core` is `""` when `WP_AUTO_UPDATE_CORE` is **not defined at all**, which is NOT the same as `off` — an undefined constant means WordPress applies its own default, which is `minor`. Rendering the first as the second would tell an operator their sites are not taking security releases when in fact they are. ⛔ `observed_read` is `false` when the site could not be read (a managed hosting package, or a box that did not answer). An empty `drift` is only meaningful while it is `true`; otherwise an unreachable site renders as compliant, which is the worst default for a security setting. Ungated read — requires `sites.view`.

参数

响应

此端点可能返回的错误

401 · 403 · 404 · 429 · 503