GET /v1/status/affecting

身份验证

请将 API 密钥作为 bearer 令牌发送。此端点在规范中未指明具体的权限，因此请为您的密钥赋予所需的最小权限，并通过检查响应来确认，而不是盲目假设。

此端点不需要组织 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