Official SDKs: Website Monitoring from Your Own Code

By the HostTracker Team - published August 2026

If your monitoring setup lives in code rather than a dashboard, calling raw HTTP endpoints works, but it means hand-rolling auth headers, hand-writing response types and re-learning the same quirks (cursor pagination, Unix-second timestamps) in every project. HostTracker publishes four official SDKs, one each for Python, JavaScript/TypeScript, Go and .NET, all generated from the same OpenAPI description that defines the API v2 surface. This article shows the shortest complete example for each and what is actually inside them.

Language	Package	Registry	Install
Python	hosttracker	PyPI	pip install hosttracker
JavaScript/TypeScript	@hosttracker/sdk	npm	npm install @hosttracker/sdk
Go	github.com/HostTracker/hosttracker-sdk-go	Go modules	go get github.com/HostTracker/hosttracker-sdk-go
.NET	HostTracker.Sdk	NuGet	dotnet add package HostTracker.Sdk

Why reach for an SDK instead of raw HTTP

Three things an SDK buys you over building requests by hand:

• Typed models. A monitor, a check result, a webhook delivery: each comes back as a typed object generated from the API's OpenAPI schema, not a loose JSON blob you have to guess the shape of.
• Auth handled once. You pass your API token to the client constructor a single time; every call after that carries it for you instead of you setting an Authorization: Bearer <token> header on every request.
• The Unix-second convention handled for you. The API returns timestamps as Unix seconds, and the SDKs convert them to native date/time values on the way out (the Go client exposes a FromUnix helper, the .NET client a UnixTime.ToDateTimeOffset helper) rather than leaving you to do the math.

Retries, idempotency handling and error mapping are documented specifically for the Go SDK, which the official command-line tool is also built on and shares that logic with. If your language of choice is Python, JavaScript or .NET, treat this article's examples as the baseline and check each SDK's own README for anything it adds beyond what is shown here.

Python: hosttracker on PyPI

Requires Python 3.11 or newer.

pip install hosttracker

The shortest complete example, listing monitors and printing each one's name, state and URL:

import os
from hosttracker import HostTracker

ht = HostTracker(token=os.environ["HT_TOKEN"])
page = ht.monitors.list_monitor(limit=50)
for monitor in page.data:
    print(monitor.name, monitor.state, monitor.url)

The client groups calls by resource, so ht.monitors is where every monitor-related operation lives, and list_monitor returns a page object whose .data is a list of typed monitor records.

JavaScript and TypeScript: @hosttracker/sdk on npm

Requires Node 20 or newer.

npm install @hosttracker/sdk

The same list-and-print pattern, filtering to monitors currently down:

import { HostTracker } from '@hosttracker/sdk';

const ht = new HostTracker({ token: process.env.HT_TOKEN });
const page = await ht.monitors.listMonitor({ query: { limit: 10, state: ['down'] } });
console.log(page.data.length, 'monitors down');

Method and property names follow each language's own convention (list_monitor in Python, listMonitor in JavaScript), but the shape of the call, the resource grouping and the response paging are the same idea across every SDK because they are all generated from one API description.

Go: github.com/HostTracker/hosttracker-sdk-go

Requires Go 1.24 or newer. The module sets its own default base URL (https://api2.host-tracker.com) and API version internally, so a client needs nothing but a token.

go get github.com/HostTracker/hosttracker-sdk-go

package main

import (
	"context"
	"fmt"
	"log"
	"os"

	hosttracker "github.com/HostTracker/hosttracker-sdk-go"
)

func main() {
	c, err := hosttracker.New(os.Getenv("HT_TOKEN"))
	if err != nil {
		log.Fatal(err)
	}
	resp, err := c.ListMonitorWithResponse(context.Background(), &hosttracker.ListMonitorParams{
		Limit: hosttracker.Ptr(int32(10)),
		State: &[]hosttracker.ListMonitorParamsState{"down"},
	})
	if err != nil {
		log.Fatal(err)
	}
	for _, m := range resp.JSON200.Data {
		fmt.Println(m.Id, *m.Name, hosttracker.FromUnix(*m.Created))
	}
}

This is the SDK the official CLI, ht-cli, is itself built on: the CLI's 139 commands call this Go client underneath, which is also where it inherits its retry, idempotency and error-mapping behavior from.

.NET: HostTracker.Sdk on NuGet

Targets net8.0.

dotnet add package HostTracker.Sdk

using HostTracker.Sdk;
using HostTracker.Sdk.Generated;

using var client = new HostTrackerClient(Environment.GetEnvironmentVariable("HT_TOKEN"));
var page = await client.Monitors.ListMonitorAsync(limit: 50);
foreach (var m in page.Data)
    Console.WriteLine($"{m.Name,-30} {m.State} since {UnixTime.ToDateTimeOffset(m.Since):u}");

Same shape again: a client constructed with a token, a Monitors resource group, an async list call and typed records on the way back, with a helper to turn the API's Unix-second fields into a regular DateTimeOffset.

What the SDKs cover

All four clients are generated from the same source, the public OpenAPI description, which currently defines 145 paths, 182 operations and 508 schemas across 14 resource groups. That means every SDK gets a client for whatever the API exposes: monitors, instant checks, contacts, webhooks, incidents, maintenance windows, status pages, reports and account/quota data, not just a narrow slice of it. A few representative operations, all present in every language's client under that language's own naming convention:

Path	Method	What it does
/check	POST	Start a one-off check against a url or host.
/monitor	GET	List the account's monitors, filtered, sorted, cursor-paginated.
/monitor	POST	Create a monitor, optionally with contacts and subscriptions.
/webhook	POST	Register a webhook to receive signed event deliveries.

An instant check kicked off through any SDK's check resource runs from the same 300+ checkpoints across 158 cities that the dashboard and the MCP server use, so a script built on the Python or Go client sees exactly the same coverage a human clicking "check now" would. For every list operation across every SDK, pages are cursor-paginated the same way, and writes carry the API's normal idempotency guarantees, so a retried create call does not double up on monitors.

Who can actually call the API and SDKs

Worth stating plainly, because it changes what you can build and when: API and SDK access is not part of the Free, Personal or Webmaster plans at all. It comes with the 30-day free trial, which needs no card to start, or with the Business and Enterprise plans for production use. If you are evaluating an SDK for a real integration rather than a quick script, plan on either the trial or one of those two paid tiers before you get a token that actually authenticates. Rate limits and monthly quotas differ by plan too; the API guide covers those numbers in full, since they apply the same way whether you call the API directly or through one of these clients.

Where to go next

Each SDK's own repository has the full method reference beyond the one example shown here: hosttracker-sdk-python, hosttracker-sdk-js, hosttracker-sdk-go and hosttracker-sdk-dotnet. All four are MIT licensed and generated from the same OpenAPI source, so a fix or a new endpoint lands in every language at once. The full endpoint reference lives on the API v2 docs page, and the API guide is the sibling article that walks the REST surface directly if you would rather not add a dependency at all.

If you would rather not write any client code, the same API sits behind an official CLI for shell scripts and CI pipelines (walked through in this wave's CLI article), and behind an MCP server that lets an AI assistant run checks and read monitors on your behalf, covered in this wave's MCP article. There is also a small official GitHub Action, HostTracker/check-action, for running a check as a workflow step without installing anything, and a Pipedream component package for wiring monitor events into no-code automations.

To get a token to try any of this, start the 30-day trial, no card required, or see the Business and Enterprise plans for production access once you are past the trial.