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

Autentikasi

Kirim kunci API sebagai token bearer. Kunci tersebut harus memiliki izin sites.view; kunci tanpa izin tersebut akan ditolak dengan status 403, bukan 404.

Endpoint ini tidak memerlukan id organisasi. Kunci Anda telah mengidentifikasi organisasi tempatnya berafiliasi, dan respons akan dibatasi untuk organisasi tersebut.

Coba

Ganti apa pun di dalam tanda kurung sudut dengan nilai Anda sendiri, dan placeholder kunci dengan kunci dari dasbor Anda.

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

Sudah masuk? Konsol API di dasbor Anda akan mengisi ID organisasi asli dan kunci Anda sendiri, serta menjalankan permintaan terhadap API langsung sehingga Anda dapat melihat respons aktualnya. Buka titik akhir ini di konsol API

Detail

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`.

Parameter

Tanggapan

Kesalahan yang dapat dikembalikan oleh titik akhir ini

401 · 403 · 404 · 429 · 503