Most vendors treat usage data as a secret. Worthune publishes its own aggregate usage at a public endpoint — because a platform built on show-your-work should be able to show its own.
GET /api/v1/telemetry returns the platform's usage summary to anyone who asks — no key, no signup, the same access model as every other public surface. The endpoint exists for a simple reason: a vendor asking integrators to trust published specs, published constants, and published changelogs should extend the same posture to its own operational reality. This piece reads the response field by field, then draws the design lesson integrators keep asking about.
The response, field by field
The envelope is small. An available flag says whether the telemetry store is configured — the endpoint degrades honestly rather than fabricating zeros. A windowDays field states the reporting window: thirty days. A totals object aggregates hits and errors per surface — the REST API, the MCP server, and the embed widgets counted separately, so you can see which integration pattern is carrying traffic. A daily array carries the per-day, per-surface, per-endpoint counts that the totals summarize — each row names the tool or model it counts — deep enough to see weekly shape and release-day bumps. And a privacy string states the boundary in its exact words: “Aggregate counters only — no IPs, user agents, or inputs are stored.”
| Field | Contents | What it answers |
|---|---|---|
| available | Whether the store is configured | Is this data live or absent — never invented |
| windowDays | 30 | How far back the counts run |
| totals | Hits and errors per surface | Which surfaces carry traffic and how cleanly |
| daily | Per-day, per-surface, per-endpoint counters | Shape over time — trend, spikes, quiet days |
| privacy | The aggregate-only statement | What is deliberately not collected |
What the numbers can and cannot say
The counters answer surface-level questions well: whether usage is growing, how API traffic compares to MCP traffic, whether errors track releases. They cannot answer — by construction, not by omission — who called, from where, with what inputs, or for which models at what hours a given caller works. The privacy line is not a policy promise layered on top of the data; it is a description of the schema. Data that was never written cannot be leaked, subpoenaed, or quietly monetized later, and an integrator evaluating the platform can weigh that property directly: the strongest privacy posture is the one where the reassuring sentence and the storage schema are the same fact.
Real numbers over impressive ones
A public usage endpoint has one obvious hazard: the temptation to publish only when the numbers flatter. The endpoint's design resists it. The counters are served mechanically from the same store the platform operates on, the error counts publish alongside the hit counts, and the available flag means an unconfigured store reports itself rather than serving decoration. Readers should treat the endpoint the way they treat the eval datasets — as an artifact whose value is its mechanism, not its magnitude. A small real number establishes more than a large unverifiable one, and the endpoint's job is to make it checkable on any given day.
- Fetch it like any public endpoint — no authentication, standard JSON.
- Read totals for the surface mix, daily for the shape.
- Treat errors alongside hits — the ratio is the health signal.
- Do not expect per-caller or geographic detail — it was never stored. Per-model and per-tool counts are there, in each daily row's name field.
- Borrow the schema for your own math-layer telemetry — counters by surface and day cover the operational questions.
Sources
- [1] Worthune public telemetry endpoint. https://worthune.com/api/v1/telemetry
- [2] Worthune writing: Observability for Embedded Math. https://worthune.com/writing/observability-embedded-math