The read-only API
The same record over HTTP, for dashboards, exports, and your own tooling. Read-only by construction, quiet about its internals.
The four nouns, served as JSON.
dormouse serve exposes the record over HTTP: the same targets, checks,
changes, and coverage described in volume one, in the same
vocabulary the CLI uses. It binds to loopback by default, expects to live behind your own
reverse proxy if it ever leaves the machine, and cannot write anything: there is no
endpoint that mutates state, so handing a dashboard a token never hands it a pen.
One open door for liveness, six behind the token.
| Endpoint | Returns |
|---|---|
GET /healthz | Liveness, no authentication, nothing sensitive. |
GET /api/targets | Every watched target with its selectors, interval, and policy. |
GET /api/targets/{id} | One target. |
GET /api/targets/{id}/checks | The target's check history: outcomes, timing, the raw material of coverage. |
GET /api/targets/{id}/changes | The target's detected changes with old and new values and the meaningful verdict. |
GET /api/changes | The change feed across all targets, newest first. |
GET /api/coverage | Per-target coverage: expected checks, ratio, gaps, staleness. |
A bearer token, and errors that keep secrets.
Every /api route requires a bearer token, supplied to the server through
its environment rather than a flag, so it never appears in a process list. A missing or
wrong token gets a flat refusal.
That is the API's whole personality: it will tell you everything about the record and nothing about the machinery, which is the right disposition for a service whose job is to be believed.