Uptimia is a website uptime and performance monitoring tool. With the API you can access the features you normally use in your browser via simple HTTPS calls. The API supports the standard GET, POST, PATCH and DELETE methods.

Send requests to the host where your account lives:

• https://www.uptimia.com/api/v2/ for accounts created at www.uptimia.com
• https://app.uptimia.com/api/v2/ for accounts created at app.uptimia.com (AppSumo)

An API key works only on the host that issued it. A key from app.uptimia.com sent to www.uptimia.com, or the other way round, returns 401 invalid_api_key.

Every call needs an API key — see Authentication below — then browse the available endpoints in the reference that follows.

The Uptimia API uses Bearer authentication. Include your API key in an Authorization header on every request:

Authorization: Bearer YOUR_API_KEY

1. Log in to your Uptimia account and open Settings → API Keys.
2. Click Create API key and give it a name (for your own reference).
3. Copy the key that is shown — for security you won't be able to see it again.
4. Use the key in the Authorization header of your requests.

Keep your API key secret. Don't share it or commit it to source control. If you think a key may be compromised, delete it and create a new one.

Pass the key as a Bearer token. For example, with cURL:

curl "https://www.uptimia.com/api/v2/uptime" \
  -H "Authorization: Bearer YOUR_API_KEY"

For an app.uptimia.com account, use https://app.uptimia.com/api/v2/uptime.

Failed authentication returns 401 Unauthorized with the same error envelope as every other API error (status / code / message).

A request with no Authorization header at all is rejected by the endpoint itself:

{
  "status": "error",
  "code": "unauthorized",
  "message": "Authentication required"
}

A request that does carry an Authorization header, but whose key is unknown, revoked, malformed (anything other than Bearer YOUR_API_KEY), belongs to a deleted account, was minted for a team seat that no longer exists, or was issued on the other host (www.uptimia.com vs app.uptimia.com), is rejected before the endpoint runs:

{
  "status": "error",
  "code": "invalid_api_key",
  "message": "API key invalid",
  "error_code": "invalid_api_key"
}

error_code repeats code for clients written against older versions of these docs. Read code, and treat any 401 as "not authenticated".

Every monitor carries a contacts array naming who gets alerted. Each entry is a reference, not an address:

{ "id": 41930, "is_team": 0, "is_user": 0, "is_operator": 1, "is_individual_contact": 0 }

The flag decides which kind of thing id refers to, and each kind lives in its own table with its own id sequence:

Ids are unique per kind, not across kinds. A team and a contact can both have id 41930 and mean completely different things. Always read the flags before resolving an id — never guess the endpoint.

Only is_individual_contact names a single address. The other three name a seat or group, which is expanded when the alert is sent. A monitor showing just one is_operator entry may well page a dozen addresses — every contact belonging to that seat, including ones added after the monitor was configured.

So a short contacts array does not mean few recipients. To see the addresses a monitor resolves to, use:

GET /api/v2/contacts/selected/{monitorId}/{type}

It returns your whole address book with an is_selected flag on each contact, already accounting for team, owner and seat expansion, plus an operator_id telling you which seat owns each contact.

Alerts go only to verified e-mail addresses and phone numbers. There is no setting to turn this off. A new e-mail, SMS or phone-call contact, or one whose address or number changes, starts unverified (is_confirmed 0, verified false) and gets a verification message at once: an e-mail with a confirmation link, or an SMS with a 6-digit code and a link. Verification SMS are free. Integrations need no verification.

Until the link is used or the code is entered, every alert to the contact is recorded as skipped / contact_unconfirmed in its delivery record, and an escalation step counts it as not reached.

Your own login address is verified without a message once your account e-mail is verified. A link works for 7 days, and one reminder goes out after 24 hours.

API v1. /api/v1/contacts keeps its paths and response shapes. A contact created or changed through v1 follows the same rule: it starts unverified, the verification message goes out, and it receives no alert until it is verified. v1 responses do not carry the verification fields; read them from GET /api/v2/contacts/{id}.

Instead of polling incidents, subscribe a URL to an event and Uptimia POSTs to it the moment the event happens. This is the mechanism behind the Uptimia app in Zapier, and it is open to any tool that can receive an HTTPS request — Make, n8n, Pipedream, or your own service.

monitor.down respects the monitor's alert delay ("alert after N seconds down"), the same as your contacts: an outage that recovers before the delay sends neither monitor.down nor monitor.up. An already-expired certificate or domain is a monitor.down, not an expiry.warning.

POST   /api/v2/hooks                 create a subscription
GET    /api/v2/hooks                 list your subscriptions
DELETE /api/v2/hooks/{id}            remove one
GET    /api/v2/hooks/events?event=monitor.down&limit=3
                                     recent real events, in the delivery shape (for samples)

POST /api/v2/hooks takes a JSON body with event and target_url, and optionally monitor_type and/or monitor_id to narrow the subscription to one monitor family or one monitor:

{
  "event": "monitor.down",
  "target_url": "https://example.com/uptimia/down",
  "monitor_type": "uptime",
  "monitor_id": 4471
}

It answers 201 Created with the subscription, including its secret — returned once, on creation, and never again. Store it: every delivery is signed with it. Creating a subscription that already exists (same event, target URL and filters) answers 409 Conflict with the existing subscription's id, so a client that retries a create never ends up with two. If that existing subscription was disabled (see below), it is replaced instead: the create answers 201 Created with a new id and secret.

The target URL must be https and publicly reachable; private, loopback and otherwise reserved addresses are refused. A Zapier target must be on hooks.zapier.com.

Every delivery is an HTTP POST with a JSON body and three headers:

The body carries the same keys for every event: event_id (stable per event — a retried delivery reuses it, so deduplicate on this), event, occurred_at, then the monitor (id, monitor_type, monitor_name, monitor_unique_id, monitor_url, monitor_notes, cp_url — the monitor's page in the control panel), the incident (monitor_status, severity, incident_start_time, incident_end_time, incident_duration_seconds, error_reason), the one-line message, kind and acknowledged_by. kind is ssl or domain on expiry.warning and empty otherwise (the days remaining are in message and error_reason, e.g. "will expire in 6 days"); acknowledged_by is set on incident.acknowledged and empty otherwise. When several monitors on one escalation policy fail together you receive one event per monitor, never a bundle. No event carries an acknowledge link.

• Any 2xx counts as delivered.
• 410 Gone tells Uptimia the endpoint is finished with the subscription: it is deleted and nothing more is sent. A 404 from hooks.zapier.com — what Zapier answers once a Zap is turned off — is treated the same way.
• Any other failure (a timeout, a 5xx, a refused connection) is retried five times with backoff — up to six attempts per delivery, about 15 minutes in all.
• After 25 consecutive failed deliveries (events whose every attempt failed; a single successful delivery resets the count) the subscription is disabled: its disabled_at is set, it stops receiving events, and it stays listed in GET /api/v2/hooks so you can see why the events stopped. Re-create it (the same POST /api/v2/hooks) to resume: the disabled subscription is replaced by a new one with a new secret.

Compute HMAC-SHA256 over the raw request body (before any JSON parsing) with the subscription's secret, and compare it to the header in constant time.

PHP:

$rawBody  = file_get_contents('php://input');
$expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);
if (!hash_equals($expected, $_SERVER['HTTP_X_UPTIMIA_SIGNATURE'] ?? '')) {
    http_response_code(401);
    exit;
}

Node:

const crypto = require('crypto');
const expected = 'sha256=' + crypto.createHmac('sha256', secret).update(rawBody).digest('hex');
const given = req.headers['x-uptimia-signature'] || '';
const ok = expected.length === given.length
        && crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(given));

Answer 2xx only after the signature checks out; an unsigned or mis-signed request should be rejected and never acted on.

Exchanging account credentials for an API key (mobile / native sign-in).

HTTP/website uptime monitoring — create, read, update, delete and view stats.

SSL/TLS certificate expiry and validity monitoring.