Audit, events and reporting

The audit trail, the event stream, the live socket, saved dashboards and generated reports.

Every address below is served under the control plane’s base URL. Permission is the guard the route is registered with; who holds it is read from the control plane’s own grant, so it cannot drift from what the server does. A dash means the route carries no permission guard of its own — the access tier below the table is then the whole of what stands in front of it.

Generated from Route. Hand edits to this table are overwritten on the next build — change the Go doc comment, or the generator.

Route	Permission	Who holds it	Body
GET /api/v1/audit	audit:read	an administrator only, through the wildcard grant	—
GET /api/v1/audit/export	audit:read	an administrator only, through the wildcard grant	—
GET /api/v1/audit/settings	admin	an administrator only, through the wildcard grant	—
PUT /api/v1/audit/settings	admin	an administrator only, through the wildcard grant	—
GET /api/v1/audit/stats	audit:read	an administrator only, through the wildcard grant	—
GET /api/v1/dashboards	dashboards:read	developer, operator, readonly, support	—
POST /api/v1/dashboards	dashboards:manage	developer, operator	—
GET /api/v1/dashboards/templates	dashboards:read	developer, operator, readonly, support	—
DELETE /api/v1/dashboards/{id}	dashboards:manage	developer, operator	—
GET /api/v1/dashboards/{id}	dashboards:read	developer, operator, readonly, support	—
PUT /api/v1/dashboards/{id}	dashboards:manage	developer, operator	—
GET /api/v1/events	events:read	developer, operator, readonly, support	—
GET /api/v1/reports	reports:read	developer, operator, readonly, support	—
POST /api/v1/reports/generate	reports:manage	operator	—
GET /api/v1/reports/templates	reports:read	developer, operator, readonly, support	—
DELETE /api/v1/reports/{id}	reports:manage	operator	—
GET /api/v1/reports/{id}	reports:read	developer, operator, readonly, support	—
GET /api/v1/reports/{id}/content	reports:read	developer, operator, readonly, support	—
GET /api/v1/reports/{id}/download	reports:read	developer, operator, readonly, support	—
POST /api/v1/webhooks/musa	—	—	—
GET /api/v1/ws	containers:read	developer, operator, readonly, support	—
POST /api/v1/ws/broadcast	admin	an administrator only, through the wildcard grant	—
GET /api/v1/ws/status	config:read	developer, operator, readonly, support	—

Who can reach these at all

authenticated — Behind authentication, cross-site-request-forgery validation and tenant extraction. Every call acts inside exactly one tenant.

unauthenticated — No authentication middleware on the router. The handler is responsible for whatever verification it needs.

Reachable only by an administrator

No role holds the permissions below explicitly. They are satisfied by the administrator’s wildcard grant and by nothing else, so an operator or a developer cannot call these routes however their tenant is configured. That is a role-model question rather than a documentation one; it is recorded here because a reader planning around it needs to know before they try.

• GET /api/v1/audit — needs audit:read
• GET /api/v1/audit/export — needs audit:read
• GET /api/v1/audit/settings — needs admin
• PUT /api/v1/audit/settings — needs admin
• GET /api/v1/audit/stats — needs audit:read
• POST /api/v1/ws/broadcast — needs admin

Registered more than once

Each route below is registered at more than one place in the control plane. The router serves the first registration; the rest are unreachable. Where two of them carry different permissions the table above shows the one the router uses, and both are listed here — a second registration is where a permission a reader expects to apply turns out not to.

POST /api/v1/webhooks/musa

• pkg/api/server.go:538 — no permission guard
• pkg/api/webhook_handlers.go:39 — no permission guard