No matching sections.
Host-Tracker REST API v2
A token-authenticated JSON API for monitors, incidents, contacts, alerts, maintenance windows, reports, status pages, instant checks and webhooks. These are the guides; the endpoint-by-endpoint reference is generated from the API itself.
Looking for a specific endpoint? The interactive reference renders the
OpenAPI 3.1 document API2 publishes at https://api2.host-tracker.com/openapi/v2.json - every path,
parameter, request body, response shape and failure, generated from the running code.
Quickstart
Mint a token, make a first call, create a monitor, receive a first webhook.
Authentication & scopes
The thirteen leaf scopes and seven families, what a refusal looks like, hardening a
token, and the anonymous reference tier.
Monitors
Creating, reading and editing monitors, per-type settings, locations, tags and
the bulk doors.
Alerting & maintenance
Contacts, alert and report subscriptions, the delivery log, and maintenance
windows.
Results, uptime & SLA
Raw check results, incidents, uptime and SLA figures, and generated
reports.
The query surface
One rulebook for every list: cursors, filters,
sort,
expand, fields, the
/q body twins and delta sync.
Status pages
Pages, components, declared incidents with their timeline, subscribers and
incident templates.
Instant checks
Run a one-off check from the monitoring fleet without creating a monitor, and
poll it to a result.
Account, usage & quota
Package, limits, per-domain usage, API quota headroom and shared-access
members.
Webhooks
The delivery envelope, both signature schemes with copy-paste verification,
retries, auto-disable, secret rotation and redelivery.
Jobs & idempotency
The 202-plus-job contract, two-phase destructive bulk, and where an
Idempotency-Key is mandatory.
Errors
The problem document's anatomy, and how to branch on codes instead of parsing
prose.
Versioning & deprecation
What may change without warning, what may not, and how a breaking change is
announced.
Migrate from v1
What you did in API v1, and the v2 call that does the same job - auth, paging, field
names, bulk writes, and the endpoints that have no successor.
What holds everywhere
Five rules apply to every endpoint, so no guide restates them.
| Rule | What it means |
|---|---|
| Base URL | https://api2.host-tracker.com - every path in these guides is relative to it, so
GET /monitor means
https://api2.host-tracker.com/monitor. |
| Authentication | Authorization: Bearer <token>. A small
anonymous reference tier is deliberately open - ten catalogue endpoints (the
agent fleet and its pools and IPs, the monitor / contact / report / alert / instant-check type
lists and the settings schema), eighteen published operations once their body-query twins are
counted - because they are identical for every caller and are usually read before any credential
exists. They are metered per source address instead. See
Authentication & scopes. |
| Timestamps | Integer Unix seconds, everywhere, in both directions. Never an ISO string, never
milliseconds. "created": 1785712608. |
| Collections | One envelope: { "data": [...], "nextCursor": ..., "hasMore": ... }.
Page by passing the previous response's nextCursor back as the
cursor parameter until hasMore is
false. There is no page or
offset. |
| Failures | application/problem+json (RFC 9457) with a stable
code to branch on. See Errors. |
Unknown members and parameters are refused, not ignored
A misspelled query parameter answers 422 unknown_parameter and an unrecognised
request-body member answers 422 validation_failed, both naming what was accepted
instead. This is deliberate: silently ignoring intervall would leave you with a
monitor that quietly kept its default.
v1 and v2 are separate APIs. The v1 reference documents a different
surface with a different authentication scheme. They are not interchangeable, and a v1 token is not a v2 token.