認証
ベアラー トークンとして API キーを送信します。このエンドポイントでは仕様に特定の権限が記載されていないため、キーに必要な最小限の権限を付与し、推測するのではなくレスポンスを確認してください。
組織 ID を入力する場所
このエンドポイントはクエリパラメータとして org_id を受け取ります。省略した場合はテナントサブツリー全体が対象になり、指定した場合は特定の組織のみに絞り込まれます。
組織IDは、ダッシュボードのAPIキー画面にキーのすぐ横に表示されています。これは、実行するすべての呼び出しで同じIDになります。
試してみる
アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。
curl -X GET https://api.zinndigital.com/v1/alerts \
-H "Authorization: Bearer zdk_live_…"ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブ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. |
返信
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
data | Alert[] | はい | — |
unread_action_count | integer | はい | 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… |
degraded | string[] | はい | ⛔⛔ **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