notices

GET /v1/alerts

Every open alert for this customer, most urgent first.

Gbogbo àwọn notices endpoints

Ìfàṣẹ́pọ̀

Fi bọ́kì kọ́kọ́ (bearer token) ránṣẹ́ gẹ́gẹ́ bí àmì ìdánimọ̀ API. Ibùdó yìí kò sọ àṣẹ pàtó kan nínú àlàyé rẹ̀, nítorí náà fún kọ́kọ́ rẹ̀ ní ohun tó kéré jù lọ tí ó nílò kí o sì ṣàyẹ̀wò ìdáhùn náà dípò kí o kàn rò ó.

Ibùdó àmì ìdánimọ̀ ilé-iṣẹ́ rẹ sí

Oju-iwọle yii nlo org_id gẹgẹbi ayẹwo ibeere. Fi silẹ ni ita yoo si bo igi iyalo rẹ lapapọ; ranṣẹ si lati dín ibeere naa kù si ajọ kan.

Id àjọ rẹ wa lórí ojú-ìwákòòkò àwọn bọ́tìnnì API nínú daṣibọọdú rẹ, lẹ́gbẹ̀ẹ́ bọ́tìnnì náà gan-an. Ó jẹ́ ìd kan náà nínú gbogbo ìpè tí o bá ṣe.

Gbiyanju rẹ

Rọ́pọ̀ èyíkéyìí nínú àwọn àmì ìtọ́ka < > pẹ̀lú iye tirẹ̀, àti àmì ìdánimọ̀ bọ́tìnnì náà pẹ̀lú bọ́tìnnì kan láti inú dásibọ̀ọ̀dù rẹ.

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

Ṣé o ti wọlé? Iwọ̀n api ní nú ìgbékalẹ̀ rẹ kún id àjọ gidi rẹ ati bọtini tirẹ, o si nṣiṣẹ ibeere na lòdì si api gidi ki o le rii esi gidi na. Ṣí ojú abáná yìí sílẹ̀ nínú kọnsólù API

Àwọn kúlẹ̀kúlẹ̀

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.

Àwọn ìpìlẹ̀

OrúkọIruTí a nílòKini o jẹ
org_id (query)stringBẹẹkọ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.

Idahun

OrúkọIruTí a nílòKini o jẹ
dataAlert[]Bẹẹni
unread_action_countintegerBẹẹniThe 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[]Bẹẹni⛔⛔ **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…

Awọn aṣiṣe ti ibudo ipari yii le da pada

401 · 429