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

Hitelesítés

Küldjön egy API-kulcsot bearer tokenként. A kulcsnak rendelkeznie kell a(z) sites.view jogosultsággal; az ezzel nem rendelkező kulcsok esetén a rendszer 403-as hibát ad vissza 404 helyett.

Ez a végpont nem fogad el szervezeti azonosítót. Az Ön kulcsa már azonosítja azt a szervezetet, amelyhez tartozik, és a válasz is erre vonatkozik.

Próbálja ki

Cserélje ki a hegyes zárójelek közötti részt a saját értékeivel, a kulcshelyőrzőt pedig a vezérlőpultján található kulccsal.

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

Be van jelentkezve? A vezérlőpultban lévő API-konzol kitölti a valós szervezetazonosítóját és a saját kulcsát, és a kérést az éles API-n futtatja, hogy láthassa a tényleges választ. Nyissa meg ezt a végpontot az API konzolban

Részletek

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

Paraméterek

Válasz

Hibák, amelyeket ez a végpont visszaadhattatlan

401 · 403 · 404 · 429 · 503