The Status Page plugin's API

All under /api/v1/x/status/, 404 while the plugin is off (it needs Incident Management on). Reading needs status:read, the settings status:admin (admins). Incidents go on the status pages with Incident Management's API (public, publicTitle). Guide: status page.

Endpoint	What
GET pages?orgId=	The organization's status pages (portals that are on and have one): { portals: [{ id, name, slug, url, subscribers }] }. 404 for an organization you can't see a unit in.
GET settings/<orgId>, PATCH settings/<orgId>	Admins: { portalIds }, the portals with a status page (this organization's only, 400 bad_portal); the GET also lists every portal of the organization (with statusPage, url and confirmed subscribers) and the organizations to pick from.
GET public/<slug>?locale=	No sign-in: a portal's status page (404 without one): { portal, brand, ongoing, recent } with public titles, impact (major, partial, degraded), status and public updates only.
POST public/<slug>/subscribe, …/confirm, …/unsubscribe	No sign-in: { email, locale } sends a confirmation email (five tries an hour from one IP address); { token } from the email's links confirms or unsubscribes.

It hooks into Incident Management through IncidentsApi.statusPages: subscribers get an email when a public incident goes on a page, with every customer update sent to the page, when it is resolved and when it comes back. Its portal page status is listed for the portals that have one. Until 2026-10-22 the public routes were Incident Management's, at /api/v1/x/incidents/public/status/<slug>.

MCP tools: list_status_pages (status:read), change_status_pages (status:admin, admins). Audited: settings (status.settings.updated, which pages were added and taken away). No webhook events of its own; Incident Management's incidents.customer_update_sent has status_page.