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

Նույնականացում

Ուղարկեք API բանալին որպես bearer token: Բանալին պետք է ունենա 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