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

การยืนยันตัวตน

ส่ง API key ในรูปแบบ bearer token คีย์ดังกล่าวต้องมีสิทธิ์ sites.view หากไม่มีสิทธิ์ ระบบจะปฏิเสธด้วยรหัส 403 แทนที่จะเป็น 404

ปลายทางนี้ไม่ต้องใช้รหัสองค์กร คีย์ของคุณระบุองค์กรที่เป็นเจ้าของอยู่แล้ว และการตอบกลับจะถูกจำกัดขอบเขตไว้เฉพาะองค์กรนั้น

ทดลองใช้เลย

แทนที่สิ่งใดๆ ที่อยู่ภายในวงเล็บแหลมด้วยค่าของคุณเอง และตัวยึดตำแหน่งคีย์ด้วยคีย์จากแดชบอร์ดของคุณ

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

เข้าสู่ระบบแล้วใช่ไหม คอนโซล API ในแดชบอร์ดของคุณจะเติมรหัสองค์กรจริงและคีย์ของคุณเองโดยอัตโนมัติ และทำการส่งคำขอไปยัง 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