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

প্রমাণীকরণ

একটি বিয়ারার টোকেন হিসেবে একটি এপিআই কি পাঠান। কি-টির অবশ্যই sites.view অনুমতি থাকতে হবে; এটি ছাড়া কোনো কি ৪০৪ নয়, বরং ৪০৩ ত্রুটি দিয়ে প্রত্যাখ্যাত হবে।

এই এন্ডপয়েন্টটি কোনো অর্গানাইজেশন আইডি নেয় না। আপনার কীটি ইতিমধ্যে এটি যে অর্গানাইজেশনের অন্তর্গত তা শনাক্ত করে এবং প্রতিক্রিয়াটি সেই অনুযায়ী নির্ধারিত হয়।

চেষ্টা করুন

কোণ বন্ধনীতে থাকা যেকোনো কিছু আপনার নিজস্ব মান দিয়ে এবং কী প্লেসহোল্ডারটি আপনার ড্যাশবোর্ডের একটি কী দিয়ে প্রতিস্থাপন করুন।

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

লগ ইন করা আছে? আপনার ড্যাশবোর্ডের এপিআই কনসোল আপনার আসল অর্গানাইজেশন আইডি এবং আপনার নিজের কি পূরণ করে দেয়, এবং লাইভ এপিআই-এর বিপরীতে অনুরোধটি চালায় যাতে আপনি প্রকৃত প্রতিক্রিয়া দেখতে পান। এই এন্ডপয়েন্টটি এপিআই কনসোলে খুলুন

বিবরণ

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