notices

GET /v1/alerts

Every open alert for this customer, most urgent first.

تمام notices اینڈ پوائنٹس

توثيقِ شناخت

ایک API کلید بطور بیر ٹوکن (bearer token) ارسال کریں۔ یہ اینڈ پوائنٹ اسپیسیفیکیشن میں کسی مخصوص اجازت کا ذکر نہیں کرتا، اس لیے فرض کرنے کے بجائے اپنی کلید کو کم از کم درکار اجازت دیں اور رسپانس چیک کریں۔

جہاں آپ کی تنظیم کی آئی ڈی آتی ہے

یہ اینڈ پوائنٹ org_id کو بطور کوئری پیرامیٹر لیتا ہے۔ اسے چھوڑ دیں اور کال آپ کے پورے ٹیننسی سب ٹری کا احاطہ کرے گی؛ کال کو کسی ایک آرگنائزیشن تک محدود کرنے کے لیے اسے بھیجیں۔

آپ کی تنظیم کی آئی ڈی آپ کے ڈیش بورڈ پر API کیز کی سکرین پر، خود کلید کے ساتھ موجود ہوتی ہے۔ یہ آپ کی کی جانے والی ہر کال میں ایک ہی آئی ڈی ہوتی ہے۔

آزمائیں

کوئی بھی چیز جو زاویہ دار قوسین میں ہو اسے اپنی اقدار سے بدلیں، اور کلیدی پلیس ہولڈر کو اپنے ڈیش بورڈ کی کسی کلید سے بدلیں۔

curl -X GET https://api.zinndigital.com/v1/alerts \
  -H "Authorization: Bearer zdk_live_…"

لاگ ان ہیں؟ آپ کے ڈیش بورڈ میں موجود API کنسول آپ کی حقیقی تنظیم کی آئی ڈی اور آپ کی اپنی کلید خود بخود پُر کر دیتا ہے، اور لائیو API پر درخواست چلاتا ہے تاکہ آپ اصل ردعمل دیکھ سکیں۔ اس اینڈ پوائنٹ کو API کنسول میں کھولیں

تفصیلات

docs/87. What the bell in the dashboard header reads. ⚖️ Owner ask 2026-08-26: *"maybe have an alerts bit somewhere like the other hosting platfroms do that has like an ! when something is open and then a list of them, like in other enterprise apps type of thing."* Unions seven sources: the customer's live **notices** (maintenance, DNS drift, a lost delegation, a paused posting run, a stranded card, a new PHP build, a certificate lapsing), an **expired or expiring stored card**, a **past-due subscription**, **domains** expiring without auto-renew or already lapsed, **suspended / restricted / quarantined** sites and orgs, any **supplier** we depend on reporting degraded or out, **our own** published open incidents and announced windows, and sites with **malware** on them. ⛔ The last two are each deliberately distinct from the one before it. `incidents` is not `upstream` — that reports a *supplier* being unwell, this reports **Zinn®**, and a customer whose site is slow wants the second far more. `security` is not the suspended/restricted/quarantined family — those are *enforcement outcomes* and the site is already off, where an infected site inside its grace window is still serving and the customer can still act. A site that is both appears in both, and that is deliberate: the second alert is the reason for the first. ⛔ No permission key — being told your card has expired is not a privilege. Gating it would mean a member whose role lacks `org.read` silently never learns their sites are suspended. ⛔⛔ **This shipped in the same change that stopped platform notices bannering on every page.** Landing that alone would have made maintenance *unreachable* from `/sites` rather than merely quieter — a false all-clear with nothing red (§2.44). A banner policy without a bell is not a smaller feature, it is a worse one. ⛔ The header calls this on every page, so it is seven bounded queries against indexed columns and reaches no vendor (§2.16). Every count that could be per-site is a grouped aggregate returning ONE row, so an estate with 40,000 suspended or infected sites produces one alert saying so rather than 40,000.

پیرامیٹرز

نامقسملازمییہ کیا ہے
org_id (query)stringنہیںNarrow to one organization. Omitted, the caller's whole accessible subtree is considered. An id outside that scope narrows to nothing rather than 403-ing.

جواب

نامقسملازمییہ کیا ہے
dataAlert[]ہاں
unread_action_countintegerہاںThe badge. Unread `critical` + `action` items only. ⛔ Computed server-side rather than by counting `data` in the client — a second copy of "which severities count" is a copy tha…
degradedstring[]ہاں⛔⛔ **Non-empty means the list above is INCOMPLETE.** Alert providers that raised, by name. A failing provider contributes nothing, and nothing is the reassuring value — without…

وہ خرابیان جو یہ اینڈ پوائنٹ واپس کر سکتا ہے

401 · 429