digiWatcher API

Connecting

The account owner creates a key in Integrations and API → API keys. The full key is shown once. Store it in your tool’s credential storage and send it in the Authorization header over HTTPS.

curl 'https://digiwatcher.com/api/v1/monitors?limit=50' \
  -H "Authorization: Bearer $HLIDAC_API_KEY"

In n8n, use HTTP Request, the GET method, and a Header Auth credential: name Authorization, value Bearer and your key separated by a space. The key belongs on the server; don’t put it in a URL or in a public website’s JavaScript.

Endpoints

A key gives access to its whole account or only to selected monitors. The scope also applies to incidents and MCP. Deleting all selected monitors leaves the key with no accessible data. Existing keys stay read-only for the whole account. Responses don’t contain monitor URLs, passwords, tokens, HTTP headers, diagnostic errors, or incident notes.

Operational actions

A “Read and operational actions” or “Configuration management” key can call the following PATCH endpoints. Send JSON with a single boolean field. Repeating the same action is safe. A read-only key gets 403; an object outside the scope returns 404.

• PATCH /api/v1/monitors/{id} with {"paused":true} pauses checks; false resumes them.
• PATCH /api/v1/incidents/{id} with {"acknowledged":true} acknowledges the incident and silences further reminders; false removes the acknowledgment.

The API doesn’t create accounts or alert contacts. Existing alert contacts and a group from your own account can be assigned in the monitor configuration.

Monitor configuration

Requires a “Configuration management” key. POST /api/v1/monitors creates a monitor; only with a key for the whole account. PUT /api/v1/monitors/{id} replaces the whole configuration. DELETE on the same address deletes the monitor, including its history. PUT and DELETE respect the scope of selected monitors. Plan limits apply.

POST requires an Idempotency-Key header with 8–120 characters (letters, digits, hyphen, underscore, period, colon). A retry with the same key and the same JSON body, including field order, returns the original ID. A changed body returns 409. After the original monitor is deleted, use a new key.

{
  "name": "Firemní web",
  "type": "http",
  "url": "https://example.com/",
  "interval_s": 300,
  "timeout_ms": 15000,
  "confirmations": 2,
  "contact_ids": [],
  "json_assertions": null
}

POST returns 201 and data.id; a retry returns 200 and replayed:true. PUT returns 200 and data.id. For PUT, send the complete configuration you want: omitted fields get default values, and omitted contact_ids removes the assigned alert contacts. The monitor’s status and history are kept. GET doesn’t return secrets or the complete configuration, so keep its source in your automation.

Optional: method, request_headers (JSON text), request_body, auth_user, auth_pass, keyword and keyword_mode, accepted_statuses, group_id, contact_ids. json_assertions is a JSON text array of rules with path in JSON Pointer format, op (exists, equals, not_equals, contains, gt, lt), and value where needed. Up to 20 rules; supported by HTTP and keyword monitors.

Pagination and data

A monitor’s status can be up, down, blocked (checks blocked), pending, paused, or stale (data out of date). last_observed_status keeps the last observed status, last_checked_at the time of the check, and stale_after_ms the age tolerance. The tolerance respects the plan’s interval. Maintenance returns pending and in_maintenance; stopped accounts or monitors return paused. Disagreement between monitoring locations or too few responses returns pending and measurement_issue: split or insufficient; an outage isn’t reported without confirmation. A blocked check returns blocked and measurement_issue: blocked. For both blocked and unconfirmed checks, last_attempt_at contains the time of the last attempt, and staleness (stale) is judged by it, so a stopped scheduler doesn’t stay hidden. Such an attempt doesn’t count toward uptime; last_checked_at stays the time of the last conclusive check.

Lists are sorted by ID in ascending order. The limit parameter defaults to 50, with a maximum of 100. Load the next page with after set to pagination.next_after. A null value means the end of the list.

{
  "data": [
    {
      "id": 12,
      "name": "Firemní web",
      "type": "http",
      "status": "up",
      "paused": 0,
      "interval_s": 300,
      "last_checked_at": 1789900000000,
      "last_response_ms": 150,
      "created_at": 1789000000000
    }
  ],
  "pagination": {
    "next_after": null
  }
}

Details return a data object. Times are Unix timestamps in milliseconds. paused and acknowledged are 0 or 1. An incident contains id, monitor_id, started_at, resolved_at, and acknowledged; resolved_at is null for an open incident.

Monitor details add uptime with 24h, 7d, and 30d windows. Each contains from, to, resolution, percent, checks, avg_response_ms, observed_ms, and coverage_percent. percent is the share of monitored time without a confirmed outage (unconfirmed errors of individual checks don’t count). Without checks, percent is null. coverage_percent tells you what part of the window since the monitor was created has actual checks; 100% uptime with low coverage doesn’t confirm the whole period. Response time is the average of successful checks.

History older than 14 days is kept per day in UTC. For the 30-day window, the first day counts in full and resolution is day; from shows the actual start. Short windows have resolution check and an exact time boundary.

To catch status changes of existing incidents, load their details or the list again. The after cursor selects new IDs, not updates to older incidents.

Limits and errors

60 requests per minute per account, shared by all its keys. Up to 300 requests per minute from one IP; after 30 invalid authentications in a minute, further invalid attempts are temporarily rejected.

An error has the form {"error":{"code":"unauthorized","message":"Chybí platný API klíč."}}.

• 400: invalid parameters.
• 401: missing, revoked, or expired key.
• 403: the key isn’t allowed to perform the operational action.
• 404: the object doesn’t exist or is outside the key’s scope.
• 405: method not supported.
• 429: wait the number of seconds given in the Retry-After header.

An account can have up to 10 keys, including expired ones. Validity is 1–365 days, 90 by default. The owner can revoke a key immediately. Blocking the account, blocking the key’s creator, or removing their owner role suspends access; deleting the creator removes the key. Re-enabling the account or the creator restores keys that are still valid.