GET /v1/status/affecting

認証

ベアラー トークンとして API キーを送信します。このエンドポイントでは仕様に特定の権限が記載されていないため、キーに必要な最小限の権限を付与し、推測するのではなくレスポンスを確認してください。

このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。

試してみる

アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。

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

ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く

詳細

⚖️ Owner, 2026-08-24: *"when the ai things check sites and people submit tickets and things, does it count for outages and like tell them this is caused by x outage and we are working on it already no need to submit a ticket type of thing and link them to status to follow for updates when it's resolved."* ⭐ Deliberately CHEAP and separate from `POST /v1/tickets/deflect`, which runs live DNS-backed probes and is therefore behind a button. The requirement is that an open incident is surfaced BEFORE the customer writes anything, so this must be able to load with the page: it reads two indexed tables and makes no network call. ⭐ The same read backs the AI assistant's refusal panel and the MCP server, so all three surfaces answer from one implementation rather than three that drift. ⛔ Relevance is a real test. A maintenance window is returned only while it is OPEN and only when it touches a region this organisation actually has a site in. Telling a customer a known outage explains them when it does not is worse than saying nothing. ⛔ The organisation comes from the caller's own scope; there is no `org_id` parameter. An attacker-chosen one would be a cross-tenant read of another tenant's placement footprint.

返信

このエンドポイントが返すエラー

401 · 429