HTTP routes

Every route below is served on FANOUT_HTTP_ADDR (:7520 by default). Telemetry does not arrive here — OTLP has its own two listeners, described in send your first telemetry.

Not the whole surface yet

This covers the routes registered in internal/api. The operational and protocol routes — /-/metrics, /debug/pprof/*, /mcp and /api/mcp — are registered elsewhere and are not in this table yet; they are described in endpoints. Tracked in #188.

Most of this is not a public API

The /api/* routes are the browser client’s own backend. They are listed here so an operator can see the whole surface and what guards it — not as an interface to build against. They change with the client, without notice and without migration paths.

The supported programmatic interface is MCP, at /mcp — see MCP tools. The stable non-MCP surfaces are OTLP ingest, and the operational endpoints in endpoints.

Two exceptions worth knowing, because HTTP is currently the only way to reach them: alert rules (/api/rules, /api/alerts) and ingest-token rotation (/api/settings/ingest). Neither has a browser page yet.

The Requires column is not a description of the rule. It is the answer the authorization middleware gives for that exact method and path, so a route cannot be documented as public while the server treats it otherwise. Capabilities map to roles in roles.

Method	Path	Requires
GET	/.well-known/oauth-authorization-server	protocol handshake
GET	/.well-known/oauth-protected-resource	protocol handshake
GET	/.well-known/oauth-protected-resource/mcp	protocol handshake
GET	/api/alerts	telemetry:read
GET	/api/alerts/summary	telemetry:read
POST	/api/auth/login-link	none
POST	/api/auth/logout	any signed-in user
GET	/api/auth/me	any signed-in user
GET	/api/auth/oauth/authorize	any signed-in user
POST	/api/auth/oauth/authorize	any signed-in user
GET	/api/auth/oidc/callback	none
GET	/api/auth/oidc/start	none
POST	/api/auth/setup	none
POST	/api/auth/start	none
GET	/api/auth/status	none
POST	/api/auth/verify	none
GET	/api/dashboard	dashboards:manage-own
PUT	/api/dashboard	dashboards:manage-own
GET	/api/dashboards	dashboards:manage-own
POST	/api/dashboards	dashboards:manage-own
DELETE	/api/dashboards/:id	dashboards:manage-own
GET	/api/dashboards/:id	dashboards:manage-own
PUT	/api/dashboards/:id	dashboards:manage-own
GET	/api/health	none
GET	/api/observability/logs	telemetry:read
GET	/api/observability/overview	telemetry:read
GET	/api/observability/performance	telemetry:read
GET	/api/observability/topology	telemetry:read
GET	/api/observability/trace	telemetry:read
GET	/api/rules	telemetry:read
POST	/api/rules	alerts:manage
DELETE	/api/rules/:id	alerts:manage
PUT	/api/rules/:id	alerts:manage
POST	/api/rules/:id/test	alerts:manage
GET	/api/settings/ingest	ingest:read-metadata
POST	/api/settings/ingest/rotate-token	ingest:manage
GET	/api/users	users:manage
POST	/api/users	users:manage
DELETE	/api/users/:id	users:manage
PUT	/api/users/:id	users:manage
POST	/api/users/:id/logout-all	users:manage
GET	/healthz	none
POST	/oauth/register	protocol handshake
POST	/oauth/token	protocol handshake
GET	/readyz	none

What the requirements mean

• none — reachable without a credential. The health endpoints are deliberately here: a probe that needs a credential fails for the wrong reason during an outage.
• any signed-in user — a session, but no particular capability.
• protocol handshake — the OAuth and MCP endpoints, which authenticate as part of their own protocol rather than through the middleware.
• a named capability — the caller’s role must carry it.
• or a service credential — additionally reachable without a browser session, which is how a scraper reaches the metrics endpoint.