Skip to main content
Three read routes answer questions about a team as a whole rather than about one trace: which tag keys exist, which services report and how much they have lost, and whether the Vexlo server itself is healthy. Every response body on this page was captured from a server seeded with the spec’s conformance trace, on team fixture with environment prod. $READ_TOKEN holds a read token whose team-set includes fixture.

GET /v1/tags

Lists the tag keys seen on the team’s traces, key ascending, with the services that declared each key and how many distinct values it has carried.
The conformance trace declares one tag, order_id, with one value. Call this route before filtering traces by tag_key or asking for related traces: it tells you how a team spells its keys.

GET /v1/coverage

Reports service coverage: one row per service (or per service and environment when filtered) with the last 24 hours of traces and loss, and the number of distinct marked functions the function index has seen for it. The route is never paginated.
The same request narrowed to environment=prod adds the environment field to the row:
The route does not enumerate a team’s environments. Without ?environment=, every environment folds into one row per service that carries no environment field. Each row of GET /v1/traces carries its own environment instead. Per-trace loss facts live in each trace’s coverage block.

GET /v1/health

Reports the server’s storage state and, for the token’s team-set, each service’s recent loss. The route is authenticated.
stubs_swept_24h is team-level rather than per service: a trace whose trace-open never arrived has no service, because that is the record the field lives on. A non-zero value with no matching records_lost_24h means records are reaching the server whose trace-open did not. A healthy server answers 200. A degraded one answers 503 with the same body shape and "status": "degraded"; no degraded response is shown here because none was captured. The 503 body is data, not the error envelope.