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

المصادقة

أرسل مفتاح واجهة برمجة التطبيقات (API key) كرمز حامل (bearer token). يجب أن يحمل المفتاح إذن sites.view؛ والمفتاح الذي لا يملكه يُرفض بالرمز 403 وليس 404.

لا يقبل هذا الطرف أي معرف للمؤسسة. يحدد مفتاحك بالفعل المؤسسة التي ينتمي إليها، وتكون الاستجابة محصورة في نطاقها.

جربه الآن

استبدل أي شيء بين أقواس زاوية بقيمك الخاصة، والعنصر النائب للمفتاح بمفتاح من لوحة تحكمك.

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

هل سجلت الدخول؟ تقوم وحدة تحكم واجهة برمجة التطبيقات في لوحة التحكم الخاصة بك بربط معرف مؤسستك الحقيقي ومفتاحك الخاص، وتنفذ الطلب مقابل واجهة برمجة التطبيقات المباشرة لتتمكن من رؤية الاستجابة الفعلية. افتح هذه النهاية الطرفية في وحدة تحكم 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