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

Баталгаажуулалт

API түлхүүрийг bearer token хэлбэрээр илгөэнэ үү. Түлхүүр нь sites.view эрхтэй байх ёстой бөгөөд үүнгүйгээр 404 биш, харин 403 алдаа буцааж татгалзах болно.

Энэ төгсгөл цэг нь ямар ч байгууллагын 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