The Website Monitoring API: A Practical Tour

By the HostTracker Team - published August 2026

Every check, alert and webhook delivery that shows up in your HostTracker dashboard is available the same way outside it: through the API v2 REST surface. This is the tour to read before the reference docs - what the API covers, how you authenticate, and a handful of real calls you can run right now with nothing more than a token and curl.

The full surface is large - 145 paths, 182 operations and 508 schemas across 14 resource groups, all generated from a single OpenAPI document - so this article does not try to be exhaustive. It covers the four things a new integration touches first: monitors, instant checks, contacts and alerts, and webhooks. Then it points you at the SDKs, the CLI and the MCP server for building on top of it.

What the API Covers, in One Screen

At the center are monitors - the checks you configure once that then run on a schedule: list and create them through the /monitor resource, and manage them from there.

Next to them are instant checks - a one-off check you fire on demand against a url or host and read a result back for, without a monitor having to exist first. It is the same primitive behind the on-demand check button in the HostTracker dashboard, and it runs from HostTracker's own network of 300+ checkpoints worldwide, the same coverage your scheduled monitors use.

Alerts are less a separate resource than a routing decision: the contacts you register and the alert rules attached to a monitor decide who gets told when it changes state, and through which channel.

Webhooks flip that around - instead of a person getting notified, your own systems receive HostTracker's events as signed deliveries pushed to a URL you register, so you never have to poll for a state change.

That is the one-screen version. The rest of the surface - reports, incidents, maintenance windows, status pages, and more - is real and documented, just out of scope for a first tour; see the docs hub link near the end of this article.

Base URL and Authentication

The base URL is https://api2.host-tracker.com, and there is no /v2/ path segment to remember - v2 is the hostname, not a URL prefix. Every request authenticates with one header:

Authorization: Bearer $HT_TOKEN

A single bearer token (a JWT), rather than an API key paired with a session. That is a real change from the older v1 API, which "keeps working with no removal date" but gets no new capability going forward: v1 authenticates by exchanging a login and password for a token that lasts 48 hours, while v2's bearer token is long-lived by default - a 10-year lifetime unless you scope it shorter - and can also be restricted to a shorter expiry, up to 10 source IPs, and a request cap.

You mint a token from your account's API integration page, which also shows your current quota. Tokens are shown once and are not stored server-side, so save it somewhere real the moment you generate it.

Your First Calls

Three calls to try as soon as you have a token.

Run an instant check

curl -s https://api2.host-tracker.com/check   -H "Authorization: Bearer $HT_TOKEN"   -H "Content-Type: application/json"   -d '{"url": "https://example.com", "type": "http"}'

This starts a one-off check against a url or host and returns a result - no monitor needs to exist first. For a lot of integrations (a deploy script, a CI gate, a one-time "is this actually up right now") this single call is the entire job.

Add "strictTls": true to the same body and, for http checks, the handshake now fails on an untrusted root, a hostname mismatch or a self-signed certificate instead of quietly reporting the check as fine - certificate problems that the default relaxed handshake does not catch, because expiry is the only thing the relaxed mode was ever built to flag. That same flag is what powers HostTracker's SSL checker page; the full write-up on automating certificate checks with it is a sibling article to this one, Automate SSL Certificate Expiry Checks.

List your monitors

curl -s "https://api2.host-tracker.com/monitor?state=down&limit=20"   -H "Authorization: Bearer $HT_TOKEN"

The list endpoint is filtered, sorted and cursor-paginated, with state and limit among the query parameters it accepts - the same filters the CLI's monitors list command exposes at the shell. Timestamps in the response come back as Unix seconds, which is why every official SDK ships a small helper to turn them back into a date - Go's FromUnix, .NET's UnixTime.ToDateTimeOffset, and so on.

List, then register, a webhook

curl -s https://api2.host-tracker.com/webhook   -H "Authorization: Bearer $HT_TOKEN"

That lists whatever is already registered on the account. Registering a new one is a POST with the URL you want deliveries sent to:

curl -X POST https://api2.host-tracker.com/webhook   -H "Authorization: Bearer $HT_TOKEN"   -H "Content-Type: application/json"   -d '{"url": "https://your-app.example.com/hosttracker-webhook"}'

Deliveries to that URL are signed, so your endpoint can confirm an event actually came from HostTracker rather than from anyone who happened to guess the URL.

Webhooks: Push Instead of Poll

Once your first calls work, a webhook is usually the next thing worth wiring up. A lot of what you would otherwise poll for - a monitor going down, an incident opening - can be pushed to your own system the moment it happens instead. Beyond registering an endpoint, the API also supports testing a webhook on demand and reviewing, and redelivering, individual past deliveries, so a receiver that was briefly down on your end does not mean a permanently lost event.

Beyond curl: SDKs, the CLI and the MCP Server

curl gets you moving fast, but you probably will not stay there for long.

HostTracker publishes four official SDKs - Python, JavaScript/TypeScript, Go and .NET - all generated from the same OpenAPI document as the API itself, so a call like listing monitors becomes one typed method instead of a hand-built request and a hand-written response type. The full tour of all four, with install commands and working code for each, is the sibling article Official SDKs: Website Monitoring from Your Own Code.

If your workflow lives in a shell or a CI pipeline rather than application code, the ht-cli command-line tool drives the same v2 surface directly - 139 commands across 14 groups, generated from the same OpenAPI document plus a hand-written layer for auth, output and paging. See Uptime Monitoring from the Command Line: the HostTracker CLI.

And if you want an AI assistant to run checks and manage monitors on your behalf, using your own token, the HostTracker MCP server exposes 65 tools over this same API surface. Walk through connecting it in Let AI Assistants Run Your Uptime Checks: the MCP Server.

Who Can Actually Call the API

One honest caveat before you build anything real on top of this: API access is not part of the Free, Personal or Webmaster plans. None of those plans include API, SDK, CLI or MCP access at all. You need either a Business or Enterprise plan, or the 30-day free trial, which does include full API access and needs no card to start.

Rate limits scale with the plan:

Plan	Reads per minute	Writes per minute	Reads per month	Writes per month
30-day trial	10	5	10,000	500
Business	60	30	100,000	20,000
Enterprise	120	60	1,000,000	100,000

Every response carries RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy headers, and a 429 response adds Retry-After, so a client can back off automatically instead of guessing.

Where to Go Next

The full endpoint-by-endpoint reference lives at the API v2 docs page. The raw OpenAPI document behind it is served live at api2.host-tracker.com/openapi/v2.json, generated from the source at github.com/HostTracker/openapi - point your own codegen at it if you would rather build a client than use one of the official ones.

Start the 30-day trial at sign up, or go straight to plans and packages if you already know you want Business or Enterprise. And if you would rather browse the developer surface as a whole before picking a starting point, the landing pages cover each piece on its own: the API, the SDKs, the CLI, and the MCP server.