Uptime monitoring API: manage monitors, alerts and status pages from code

Sign in, open Integrations - API on your profile, choose the scopes the integration needs - monitor, contact, webhook, check, status page, report, incident, maintenance, job or account, each as read or write, or the whole family - and mint the token. It is shown once and is not stored on our side, so copy it immediately; if you lose it, mint another. Left alone a token lasts ten years, but you can set a shorter expiration, an IP allow-list of up to ten addresses, and a per-token request cap.

They are set by plan, not by endpoint. The 30-day trial gets 10 reads and 5 writes per minute, 10,000 reads and 500 writes a month. Business gets 60 reads and 30 writes per minute, 100,000 reads and 20,000 writes a month. Enterprise gets 120 reads and 60 writes per minute, 1,000,000 reads and 100,000 writes a month. Every response carries RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset and RateLimit-Policy headers, and a 429 adds Retry-After, so you back off exactly as long as needed instead of guessing.

No. The Free, Personal and Webmaster plans do not include API access at all - there is no free tier of the API on its own. The 30-day trial does include it, with no card required, which is the way to evaluate the API before committing to a paid plan. Production use needs Business or Enterprise.

Webhooks, for anything time-sensitive. Fifteen event types cover monitor state changes, incidents, monitor lifecycle, maintenance and expiry warnings, delivered as a signed HTTPS POST with a five-attempt retry ladder over about 2.6 hours for the events the monitoring engine raises. Poll GET /monitor or GET /monitor/incident when you only need current state on your own schedule, or as a fallback before you have a receiving endpoint wired up - both ride the same token and the same scopes.

Any write accepts an Idempotency-Key header, and nine operations - the bulk create, update and delete doors, reset-stats, and the status-page incident writes - refuse without one, because a retried request after a timeout must never repeat the effect. Bulk operations answer 202 with a job id instead of doing the work inline; poll GET /job/{id} or name a webhook as a callback, and read state (queued, running, succeeded, partial, failed, interrupted) rather than assuming success or failure from the HTTP status alone.

No, you do not have to migrate: API v1 keeps working with no removal date. But it gets no new capability - maintenance windows, webhooks, contact groups, status pages, instant checks and the bulk job doors exist only in v2, and v1 authenticates with a login-and-password exchange for a 48-hour token rather than a long-lived bearer token. New integrations should start on v2; the migration guide maps every v1 endpoint to its v2 equivalent.

Both are part of the same REST API v2. The status-pages resource group creates and updates public status pages and posts incidents to them; the instant-checks door runs a one-off ping, HTTP, port, DNS or traceroute check from the locations you name and returns the result in the same request, no monitor required.

Yes. The v2 API is described by a published OpenAPI 3.1 document at https://api2.host-tracker.com/openapi/v2.json (source at github.com/HostTracker/openapi), and it is the same document the four official SDKs are generated from - any OpenAPI-generator-compatible tool can produce a client in a language we do not ship. You lose the hand-written layer the official SDKs add - retries, idempotency keys, paging, webhook verification - but the endpoint coverage is identical.