GET /v1/sites/{siteId}/wordpress/cron

身份验证

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

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

免费试用

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

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

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

详细信息

Every task in WordPress's own scheduler, soonest first, with when each is next due. ⛔⛔ This is the read that explains a site nobody can explain. WP-cron does not run on a timer — WordPress fires it on an inbound page view — so a site with no traffic never runs it, and the customer sees no scheduled posts, no plugin licence renewals and no error anywhere. Every other control we own reports the site as healthy, because it is. A stuck queue is only visible if something looks at the queue. next_run_relative is the scheduler's own human phrasing ("13 hours", "now") carried through unchanged beside the machine timestamp, rather than a second derivation of "when" that would drift from it on every refresh. ⛔ The read is not gated on the capability, so a client can render "scheduled tasks are not available on this line" alongside whatever it does know. this platform publishes no cron endpoint at any path, so this returns an empty list there and wp_cron is false on the capability map. Requires sites.view.

参数

响应

此端点可能返回的错误

401 · 403 · 404 · 429 · 503