Monitor API reference

Mon, 01 Jan 0001 00:00:00 +0000

Monitor API reference#

The JSON API a monitor agent uses to enroll with a tenpm uptime server, sync its assigned check set, and report results and status back. Generated from docs-site/assets/tenpmuptime-monitor.yaml — see that file’s header for how it’s kept in sync with the code.

Download the raw OpenAPI spec (tenpmuptime-monitor.yaml)

The JSON API a monitor agent uses to enroll with a tenpm uptime server, sync its assigned check set, and report results and status back. This is the wire contract described in agent/model and implemented by internal/server/api_handlers.go; both binaries build against the same Go structs today, so treat this document as generated-by-hand from that code, not the other way around — if the two disagree, the code is right and this file is stale. Every route except POST /monitor-api/v1/enroll requires the monitor's own API key, minted at enrollment. POST /monitor-api/v1/enroll requires an enrollment token instead (an org token or a platform token — see the security scheme below), since no monitor exists yet at that point. Error responses across every endpoint are a plain-text body (one line) with a non-2xx status, not a JSON envelope — the handlers use Go's http.Error. The 4xx/5xx responses below document status code and body meaning; there is no shared error schema. Every route here is rate-limited per client address (about 10 requests a second with a burst of 30) and answers 429 rate limit exceeded beyond that. A monitor that syncs and reports every 45 seconds is nowhere near it. Versioning (2026-09-22, path moved again 2026-09-27): every path below moved under /api/v1/ in the first pass, then to /monitor-api/v1/ in a second, unrelated to versioning itself - a new, separate customer-facing account API (/account-api/v1/..., not documented in this file) needed a path of its own and collided with this one's /api/v1/checks and /api/v1/status, so the monitor API got a distinct prefix instead of a third segment under a shared one. The rule from here on: a JSON change within v1 is additive only - a removed field or a changed meaning gets a new /monitor-api/v2/ path instead of changing what v1 means. Neither the fully unversioned form (/api/..., no version segment at all) nor /api/v1/... itself exists any more - both were renamed with no permanent alias, since every monitor deployed at each point in time was ours to redeploy. The /api/v1/... → /monitor-api/v1/... move was briefly served from both prefixes during the fleet's own migration window; that temporary routing was removed once every deployed monitor (this project's own fleet, and any private monitor a customer runs) was confirmed redeployed on a build calling the new path. Treating a prefix rename as a standing policy a third time should not be expected: the next breaking change bumps the version segment (/monitor-api/v2/...), not the prefix.

Account API reference

Mon, 01 Jan 0001 00:00:00 +0000

Account API reference#

The read-only, customer-facing JSON API for a person’s own account data — checks, monitors, results, heartbeats, notification channels, members, and plan settings — plus a full data-export endpoint. This is a different surface from the monitor API: that one is what a monitor agent uses to talk to the server, authenticated as a monitor; this one is what a person (or a script acting on their behalf) uses to read their own org’s data, authenticated with their own bearer token minted from the organisation settings page. Generated from docs-site/assets/tenpmuptime-account.yaml — see that file’s header for how it’s kept in sync with the code.

Reference on Tenpm Uptime Docs

Monitor API reference

Monitor API reference#

Account API reference

Account API reference#