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