Keine passenden Abschnitte.

Host-Tracker REST API v1

Eine stabile, token-authentifizierte HTTP-API zur Verwaltung von Website-Überwachungs-Tasks, Kontakten, Alarm-/Report-Abonnements sowie zum Auslesen von Statistiken, Ausfällen und Vorfällen.

Base URL

Jeder Pfad in diesem Dokument ist relativ zu einer Base URL zu verstehen. Zwei Einstiegspunkte bedienen dieselbe API:

In dieser Referenz bedeutet ein Aufruf wie GET tasks stets GET BASE_URL/tasks — also z. B. https://api1.host-tracker.com/tasks oder https://www.host-tracker.com/api/web/v1/tasks.

Content-Type & HTTP-Methoden

Requests und Responses sind standardmäßig application/json (siehe Konventionen für XML). Die API verwendet die üblichen HTTP-Methoden:

• GET — Entitäten lesen (Tasks, Kontakte, Abonnements, Statistiken, Ausfälle, Vorfälle, Agenten).
• POST — eine Entität anlegen oder eine Aktion starten.
• PUT — bestehende Entitäten aktualisieren.
• DELETE — Entitäten entfernen.
• PATCH — Teilaktualisierungen (wird zum erneuten Versand eines Kontakt-Bestätigungscodes verwendet).

Override der HTTP-Methode

Falls Ihr Client kein PUT, DELETE oder PATCH senden kann, senden Sie ein POST und fügen Sie einen X-HTTP-Method-Override-Header mit der gewünschten Methode hinzu. Um beispielsweise Tasks zu aktualisieren, senden Sie ein POST an tasks mit X-HTTP-Method-Override: PUT.

Konventionen

JSON-Serialisierung

JSON verwendet Property-Namen in camelCase. Null-Felder werden in Responses weggelassen (leere Arrays werden weiterhin als [] ausgegeben). Die Reihenfolge der Properties ist stabil: zuerst Identifikator und Adresse/URL, dann geerbte Felder, dann typspezifische Felder.

Datum & Uhrzeit

Antworten auf Task-Erstellung/-Abfrage führen Zeitstempel als ISO-8601-UTC-Strings (z. B. 2024-06-21T22:26:23Z). Die Endpunkte für Statistiken, Ausfälle, Vorfälle und Ergebnisse verwenden zusätzlich eine duale Darstellung: Jede Zeitangabe erscheint sowohl als Ganzzahl in Unix-Sekunden (Suffix Unix) als auch als für Menschen lesbarer String, formatiert gemäß dem im Profil hinterlegten Datumsformat und der Zeitzone des Kontos. Request-Filter akzeptieren je nach Endpunkt Unix-Sekunden und/oder formatierte Strings (bei jedem Endpunkt unten dokumentiert). Alle Unix-Zeitstempel sind Sekunden seit 1970-01-01T00:00:00Z.

XML-Content-Negotiation

Alle Endpunkte können auch XML zurückgeben. Senden Sie Accept: application/xml, um statt JSON einen XML-Body zu erhalten; die Response verwendet die klassische .NET-XmlSerializer-Darstellung desselben Objektgraphen. JSON ist das Standard- und empfohlene Format.

CORS

Cross-Origin-Requests sind zulässig. Einfache (nicht-credentialed) Requests werden von jedem Origin akzeptiert (Access-Control-Allow-Origin: *). Requests, die Cookies/Credentials mitsenden, werden nur von *.host-tracker.com-Origins akzeptiert. Aufrufer, die per Token (über den Authorization-Header, wie hier dokumentiert) arbeiten, sind von dieser Einschränkung für credentialed Origins nicht betroffen.

Authentifizierung

Jeder Endpunkt außer POST users/token und den anonymen Agent-Listen-Endpunkten erfordert eine Authentifizierung. Zwei Schemata werden akzeptiert:

• Bearer-Token — von POST users/token bezogen, gesendet als Authorization: bearer <token>. Dies ist das primäre Schema.
• HTTP Basic — Authorization: Basic <base64(login:password)>. Zugangsdaten werden als ISO-8859-1 dekodiert. Praktisch für schnelle Tests; für Automatisierung wird das Bearer-Token bevorzugt.

POST users/token anonym

Tauscht Login und Passwort gegen ein Bearer-Token. Das Token ist 48 Stunden gültig.

Request-Body

{
  "login": "your-login",
  "password": "your-password"
}

Response — 200 OK

{
  "ticket": "<bearer token>",
  "expirationTime": "2024-06-23T22:26:23Z",
  "expirationUnixTime": 1719181583
}

Bei einem Fehlschlag lautet die Response 401 mit dem maschinenlesbaren Code IncorrectLoginOrPassword (oder AccessDenied, falls der API-Zugriff für das Konto deaktiviert ist) sowie einem WWW-Authenticate: Bearer-Header.

Verwendung des Tokens

GET BASE_URL/tasks HTTP/1.1
Host: api1.host-tracker.com
Accept: application/json
Authorization: bearer 3DD135...5EE510417

Subaccount-Impersonation (forLogin)

Wenn ein Hauptkonto (Super-Account) Ihrem Subaccount Zugriff auf seine Daten gewährt hat, melden Sie sich als Subaccount an, geben aber den Login des Hauptkontos in forLogin an. Das zurückgegebene Token erlaubt Ihnen dann, das Hauptkonto genau so zu verwalten, als würden die Endpunkte für Ihr eigenes Konto aufgerufen — vorbehaltlich der vom Hauptkonto gewährten Rechte. Wurde beispielsweise nur Lesezugriff auf Überwachungs-Tasks gewährt, gelingen GET-Aufrufe, während POST/PUT/PATCH/DELETE auf Tasks abgelehnt werden.

# 1. Impersonation-Token beziehen
POST BASE_URL/users/token HTTP/1.1
Content-Type: application/json

{
  "login": "subaccount-login",
  "password": "subaccount-password",
  "forLogin": "superaccount-login"
}

# 2. Mit dem zurückgegebenen Ticket die Tasks des HAUPTKONTOS lesen
GET BASE_URL/tasks HTTP/1.1
Authorization: bearer <ticket from step 1>

curl

# Token abrufen und speichern
TOKEN=$(curl -s -X POST https://api1.host-tracker.com/users/token \
  -H "Content-Type: application/json" \
  -d '{"login":"your-login","password":"your-password"}' \
  | grep -o '"ticket":"[^"]*"' | cut -d'"' -f4)

# einen authentifizierten Endpunkt aufrufen
curl -s https://api1.host-tracker.com/tasks \
  -H "Authorization: bearer $TOKEN"

Fehler & maschinenlesbare Codes

Fehler liefern einen Standard-HTTP-Statuscode zusammen mit einem kurzen maschinenlesbaren Code, auf den Ihre Integration reagieren kann. Der Body ist eine reine Text-Beschreibung auf Englisch (kein JSON), gedacht für Menschen/Logs.

Der maschinenlesbare Code wird auf zwei Wegen übermittelt:

• X-HT-Reason-Response-Header — trägt den Code bei jeder Response und jeder HTTP-Version. Dies ist der empfohlene Weg, um den Fehlertyp zu erkennen.
• HTTP/1.1-Reason-Phrase — die Status-Zeile lautet z. B. HTTP/1.1 400 SimilarExists. Aus Gründen der Abwärtskompatibilität erhalten, aber zu beachten: HTTP/2 und HTTP/3 haben Reason-Phrases aus dem Protokoll entfernt, sodass dieses Feld leer sein kann, wenn die Verbindung HTTP/2+ aushandelt. Bevorzugen Sie X-HT-Reason.

HTTP/1.1 400 SimilarExists
X-HT-Reason: SimilarExists
Content-Type: text/plain; charset=utf-8

Same task allready exists

Referenz der Fehlercodes

Jeder von der API zurückgegebene maschinenlesbare Code, gruppiert nach Bereich, mit dem typischen HTTP-Status. Sofern nicht anders vermerkt, sind Fehler 400 Bad Request.

Authentifizierung

Tasks

Kontakte

Abonnements

Rate Limits

Requests werden pro Client und pro Endpunkt limitiert. Wird ein Limit überschritten, liefert die API 429 mit dem maschinenlesbaren Code RequestThrottled und einem Retry-After-Header (in Sekunden).

HTTP/1.1 429 RequestThrottled
X-HT-Reason: RequestThrottled
Retry-After: 1
Content-Type: application/json; charset=utf-8

"API calls quota exceeded! maximum admitted 6 per s."

Überwachungs-Tasks

GET tasks/types

Gibt das Array der dem System bekannten Task-Typ-Namen zurück:

["API","CntCheck","Counter","DNSBL","Database","DomainExp","Http",
 "Ping","Port","RusRegBL","SSLExp","Snmp","Tran","Waterfall","WebRisk"]

GET tasks/intervals

Gibt das Array der für Ihr Konto akzeptierten Überwachungsintervalle (in Minuten) zurück, z. B. [1,5,15,30,60]. Verwenden Sie beim Anlegen eines Tasks einen dieser Werte für das Feld interval; jeder andere Wert führt zu WrongInterval.

GET tasks

Listet Überwachungs-Tasks auf. Alle Query-Parameter sind optional; ohne Angabe werden alle Tasks des Kontos zurückgegeben. Wiederholen Sie einen Parameter, um ein Array zu übergeben, z. B. ?ids=guid1&ids=guid2.

Der Parameter info

Fordert zusätzliche, in jeden Task eingebettete Daten an. Kombinieren Sie Werte mit Kommas (?info=stats,subscriptions) oder übergeben Sie die äquivalente Bitmask als Ganzzahl:

?info=stats,subscriptions,results entspricht ?info=7.

Filterparameter

Response — 200 OK

Ein Array von Task-Objekten. Die genauen Felder hängen vom Task-Typ ab; die gemeinsame Basis umfasst id, name, taskType, enabled, interval, lastState, creationTime, tags, agentPools sowie (wenn über info angefordert) subscriptions, stats, results und attached. Sind Ergebnisse enthalten, trägt jedes Ergebnis mindestens timestamp (Unix-Sekunden UTC) und eventNumber; die übrigen Felder sind typspezifisch (siehe die Create-Response unten für die HTTP-Form).

GET BASE_URL/tasks?info=stats,subscriptions&taskType=Http HTTP/1.1
Accept: application/json
Authorization: bearer <token>

GET tasks/{id:guid}

Ruft einen einzelnen Task anhand seiner ID ab. Akzeptiert denselben Parameter info (sowie sdtu/edtu, wenn info=results). Gibt das Task-Objekt zurück, oder 404 NotFound, falls es nicht existiert.

POST tasks/http · tasks/ping · tasks/port · tasks/rusbl

Legt einen Überwachungs-Task des angegebenen Typs an. Bei Erfolg wird 201 Created, ein relativer Location: /tasks/{id}-Header und das vollständige angelegte Task-Objekt zurückgegeben.

Request-Body — HTTP-Task

{
  // HTTP-spezifische Felder
  "url": "https://www.example.com",        // ERFORDERLICH
  "httpMethod": "Get",                       // Get | Post | Head (Standard: Get)
  "userAgent": "MyMonitor",
  "referer": "https://www.google.com",
  "acceptHeader": "application/json",
  "followRedirect": false,
  "treat300AsError": false,                // falls gesetzt, wird followRedirect ignoriert
  "checkDnsbl": false,                       // Domain gegen DNS-Sperrlisten prüfen
  "checkDomainExpiration": false,            // Domain-Ablauf überwachen (nur bei gültigen Domains)
  "checkCertificateExpiration": false,       // TLS-Zertifikatsablauf überwachen (nur https)
  "checkRussianBlackLists": false,
  "checkWebRisk": false,
  "timeout": 40000,                          // ms bis eine Prüfung fehlschlägt
  "keywords": ["error", "maintenance"],
  "keywordMode": "ReverseAny",             // siehe Keyword-Modi unten
  "userName": "basic-auth-user",          // Zugangsdaten für die überwachte Ressource
  "password": "basic-auth-pass",
  "postParameters": "a=1\r\nb=2",          // nur bei httpMethod=Post
  "ignoredStatuses": [404, 500],

  // Felder, die für jeden Task-Typ gelten
  "interval": 5,                             // Minuten; muss ein akzeptiertes Intervall sein
  "enabled": true,
  "fullLog": false,                          // nur bei erweiterten Paketen
  "openStat": true,
  "name": "My website",
  "tags": ["production", "web"],
  "agentPools": ["westeurope", "asia"],  // siehe Hinweise unten
  "subscriptions": [ /* Inline-Abonnements, siehe unten */ ]
}

Inline-Abonnements

Das Array subscriptions abonniert Kontakte beim Anlegen für die Alarme/Reports dieses Tasks. Jeder Eintrag verwendet die Abonnement-Struktur; setzen Sie kein taskIds (es wird fest auf den neuen Task gesetzt). Wird contactIds weggelassen, werden alle Ihre bestätigten Kontakte abonniert. Report-Abonnements werden nur auf E-Mail-Kontakte angewendet.

Weitere Task-Typen

• tasks/ping — der Body trägt host plus die gemeinsamen Felder.
• tasks/port — der Body trägt host und port plus die gemeinsamen Felder.
• tasks/rusbl — Prüfung gegen die russische Registry-Sperrliste; der Body trägt url, zusätzlich ignoreWarnings, doNotSendMsgOnWarnings, prefixMatch und die gemeinsamen Felder.

Response — 201 Created (HTTP-Task)

{
  "id": "ef10cd12-93f9-e311-bec5-dc85de1f0bc2",
  "url": "https://www.example.com",
  "rawUrl": "https://www.example.com",
  "name": "My website",
  "creationTime": "2024-06-21T22:26:23Z",
  "taskType": "Http",
  "enabled": true,
  "interval": 5,
  "lastState": true,
  "openStatEnabled": true,
  "fullLogEnabled": false,
  "tags": ["production", "web"],
  "agentPools": ["westeurope", "asia"],
  "subscriptions": [
    { "alertTypes": ["Up"],   "taskIds": ["ef10cd12-...-0bc2"], "contactIds": ["4cedf037-...-0bc2"] },
    { "alertTypes": ["Down"], "taskIds": ["ef10cd12-...-0bc2"], "contactIds": ["4cedf037-...-0bc2"] },
    { "reportTypes": ["Month"], "taskIds": ["ef10cd12-...-0bc2"], "contactIds": ["4cedf037-...-0bc2"] }
  ],
  "httpMethod": "Get",
  "keywords": ["error"],
  "keywordMode": "ReverseAny",
  "timeout": 40000
}

curl

curl -s -X POST https://api1.host-tracker.com/tasks/http \
  -H "Authorization: bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://www.example.com","interval":5,"name":"My website"}'

PUT tasks & typisierte Varianten

Aktualisiert Tasks. Zwei Formen:

• Nach ID — PUT tasks/{id} (nur gemeinsame Felder), oder die typisierten PUT tasks/http/{id}, tasks/ping/{id}, tasks/port/{id}, tasks/rusbl/{id} (auch typspezifische Felder). Der Body hat dieselbe editierbare Struktur wie beim Anlegen; nur die übermittelten Felder werden geändert.
• Nach Filter — PUT tasks?<filter> (nur gemeinsame Felder) oder die typisierte PUT tasks/{type}?<filter> (fixiert den Filter auf diesen Typ). Verwendet dieselben Filterparameter wie GET tasks. Gibt den/die aktualisierten Task(s) zurück.

Das untypisierte PUT tasks / PUT tasks/{id} kann nur Felder ändern, die allen Task-Typen gemeinsam sind — für typspezifische Einstellungen einen typisierten Endpunkt verwenden.

DELETE tasks/{id:guid} & tasks

• DELETE tasks/{id} — löscht einen einzelnen Task; gibt den gelöschten Task zurück.
• DELETE tasks?<filter> — Massenlöschung anhand des Task-Filters (ein Filter kann auch im Request-Body übergeben werden). Gibt die gelöschten Tasks zurück.

POST tasks/$batch · task/$batch

Führt mehrere Task-Operationen in einem Request aus. Der Body ist ein JSON-Array von Sub-Requests; die Response ist ein JSON-Array von Sub-Responses in derselben Reihenfolge. Die Sub-Operation wird durch das letzte Segment von relativeUrl bestimmt (z. B. http → POST tasks/http). Der Request-Body muss JSON sein (Content-Type: application/json). Derselbe Mechanismus existiert für Kontakte unter contacts/$batch / contact/$batch.

POST BASE_URL/tasks/$batch HTTP/1.1
Authorization: bearer <token>
Content-Type: application/json

[
  {
    "method": "POST",
    "relativeUrl": "http",
    "contentType": "application/json",
    "content": "{\"url\":\"https://a.example.com\",\"interval\":5}"
  },
  {
    "method": "POST",
    "relativeUrl": "ping",
    "contentType": "application/json",
    "content": "{\"host\":\"b.example.com\"}"
  }
]

[
  { "code": 201, "status": "Created",
    "headers": { "Location": "/tasks/ef10cd12-...-0bc2" },
    "body": "{ ...created http task... }" },
  { "code": 201, "status": "Created",
    "headers": { "Location": "/tasks/7a20de34-...-1cd3" },
    "body": "{ ...created ping task... }" }
]

Kontakte

Kontakte sind die Ziele, die Alarme und Reports empfangen (E-Mail-Adressen, Telefonnummern für SMS/Anruf). Kontakt-IDs werden beim Anlegen von Abonnements verwendet.

GET contacts/types · contacts/delays · contacts/sms/gateways · contacts/im/gateways

Statische Aufzählungen, die von den Kontakt-Endpunkten verwendet werden:

GET contacts & contacts/{id:guid}

Listet Kontakte (optional gefiltert) auf, oder ruft einen einzelnen anhand seiner ID ab. Fügen Sie ?info=subscriptions hinzu, um die Abonnements jedes Kontakts einzubetten. Ohne Filter werden alle Kontakte des Kontos zurückgegeben.

Kontakt-Objekt

Gemeinsame Felder: id, confirmed, contactType, name, address, alertDelay, activePeriodStart/activePeriodEnd (HH:mm), activeDays, sendCost. E-Mail-Kontakte fügen reportFormat (Text/ShortText), sendNews, sendBillingNotifications hinzu; SMS-/IM-Kontakte fügen gateway hinzu.

POST contacts/email · contacts/sms · contacts/voice

Legt einen Kontakt an. Gibt 201 Created, einen relativen Location: /contacts/{id} und ein ContactOperationResult ({ contact, status }) zurück, dessen status das Ergebnis der Bestätigung meldet.

{
  "address": "ops@@example.com",          // ERFORDERLICH
  "name": "Ops mailbox",
  "alertDelay": 0,                        // Minuten; einer der Werte aus contacts/delays
  "reportFormat": "Text",               // Text | ShortText (nur E-Mail)
  "activePeriodStart": "00:00",        // optionales Ruhezeitfenster (HH:mm)
  "activePeriodEnd": "23:59",
  "activeDays": ["Monday", "Tuesday"],   // optional; Standard sind alle Tage
  "subscriptions": [ /* optionale Inline-Abonnements */ ]
}

SMS- und Anruf-Kontakte verwenden standardmäßig die Gateways twiliosms / twiliovoice, erhalten einen Standardpreis pro Nachricht und speichern die Nummer mit einem führenden +. Das Ändern von Adresse oder Gateway eines Kontakts setzt dessen Bestätigungsstatus zurück.

Werte des Bestätigungsstatus

Das Feld status des Ergebnisses meldet das Ergebnis des Bestätigungscode-Versands:

PUT contacts & typisierte Varianten

• Nach ID — PUT contacts/{id} (gemeinsame Felder), oder typisiert PUT contacts/email/{id}, contacts/sms/{id}, contacts/voice/{id}. Nur die übermittelten Felder werden geändert.
• Nach Filter — PUT contacts?<filter> oder typisiert PUT contacts/{type}?<filter> (fixiert den Filter auf diesen Typ), unter Verwendung des Kontaktfilters.

PUT contacts/im (beide Formen) liefert 400 WrongContactType.

DELETE contacts/{id:guid} & contacts

Löscht einen einzelnen Kontakt anhand seiner ID, oder löscht mehrere anhand des Kontaktfilters. Wie bei Tasks wird eine Massenlöschung mit leerem Filter mit 400 EmptyFilter abgelehnt.

Bestätigungscodes

Unbestätigte Kontakte müssen ihren Besitz mit einem kurzen, an die Kontaktadresse zugestellten Code bestätigen.

• PATCH contacts/{id}/code — den Bestätigungscode (erneut) ausstellen und versenden. Gibt ein ContactOperationResult mit einem Status wie CodeSent zurück.
• POST contacts/{id}/code — bestätigt den Kontakt durch Übermitteln des Codes. Body: { "code": "12345" }. Bei Erfolg wird der Kontakt bestätigt.

Alarme & Abonnements

Ein Abonnement verknüpft einen oder mehrere Tasks und Kontakte mit einer Menge von Alarm- und/oder Reporttypen. Ein einzelner Abonnement-Eintrag bildet das Kreuzprodukt seiner Tasks und Kontakte, wodurch je (Task, Kontakt, Typ) ein Alarm/Report entsteht.

Struktur eines Abonnements

{
  "alertTypes": ["Up", "Down"],       // beliebige aus Up, Down, RepeatedlyDown
  "reportTypes": ["Day", "Month"],     // beliebige aus Day, Week, Month, Quarter, Year
  "taskIds": ["<task guid>"],
  "contactIds": ["<contact guid>"]
}

• Mindestens eines von alertTypes / reportTypes ist erforderlich, sonst AlertsAndReportsAreEmpty.
• Wird taskIds weggelassen, gilt standardmäßig alle Ihre Tasks; wird contactIds weggelassen, gilt standardmäßig alle Ihre Kontakte. Ein explizit leeres Array bedeutet "keine".
• Report-Abonnements gelten nur für E-Mail-Kontakte — Reporttypen auf Nicht-E-Mail-Kontakten werden stillschweigend ignoriert (deren Alarm-Abonnements werden trotzdem angelegt).
• IDs, die Ihnen nicht gehören, werden ignoriert.

GET subscriptions/alertTypes · subscriptions/reportTypes

GET subscriptions

Listet Abonnements auf. Gibt einen Eintrag pro passendem Alarm- oder Report-Abonnement zurück (nie zusammengeführt). Optionale Filter:

POST subscriptions · DELETE subscriptions

Beide erwarten ein JSON-Array von Abonnement-Einträgen im Body. POST fügt die beschriebenen Abonnements hinzu (nur neue Zeilen werden eingefügt); DELETE entfernt die vorhandenen. Beide liefern 200 OK mit leerem Body. Unbekannte Alarm-/Reporttypen werden mit UnknownAlertType / UnknownReportType abgelehnt.

[
  { "alertTypes": ["Up", "Down"],
    "taskIds": ["7ee87894-b8a9-e311-beb2-dc85de1f0bc2"],
    "contactIds": ["4cedf037-d1d9-e311-bebc-dc85de1f0bc2"] },
  { "reportTypes": ["Month"],
    "taskIds": ["7ee87894-b8a9-e311-beb2-dc85de1f0bc2"],
    "contactIds": ["4cedf037-d1d9-e311-bebc-dc85de1f0bc2"] }
]

curl -s -X POST https://api1.host-tracker.com/subscriptions \
  -H "Authorization: bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '[{"alertTypes":["Up","Down"],"taskIds":["<task>"],"contactIds":["<contact>"]}]'

Statistiken & Ergebnisse

GET stats

Uptime-/Downtime-Aggregate je Task über ein Zeitfenster. Akzeptiert den Task-Filter zur Auswahl der Tasks, plus:

Response

Ein Stats-Objekt mit dem aufgelösten Fenster (duale Datumsfelder) und einem stats-Array. Jeder Eintrag trägt die Task-Referenz sowie: uptimeInMinutes/uptimeSpan, downtimeInMinutes/downtimeSpan, Wartungs-Up-/Downtimes, totalTimeInMinutes, die Prüfungszählungen pro Bucket sowie uptimePercent/downtimePercent.

GET outages

Ausfallzeiträume je Task. Akzeptiert den Task-Filter plus:

Response: ein Outages-Objekt mit dem aufgelösten Fenster und einem taskOutages-Array; jedes Element paart einen Task mit seinen outages-Zeiträumen (startTime/endTime plus Unix-Varianten, Ereignisnummern, optionalem Kommentar).

GET incident

Liste der Vorfälle (Ausfallereignisse) je Task. Akzeptiert den Task-Filter plus dieselben Fenster-/Zeitzonenparameter wie bei Ausfällen sowie:

Response: ein Incidents-Objekt mit einem taskIncidents-Array. Jeder Vorfall trägt taskId, checkId, Start-/End-Unix-Zeiten, den fehlgeschlagenen location-Wert, den error, hasSnapshot, sowie (mit fullLog) einen recheck-Block mit den OK-Standorten und den fehlgeschlagenen Standorten je Fehler.

GET incident/snapshot

Ruft das gespeicherte Response-Snapshot eines Vorfalls ab. Parameter:

Gibt das Snapshot (Zeitstempel plus erfasste Bytes) zurück, sofern vorhanden, oder null, wenn für den angegebenen Vorfall kein Snapshot existiert.

GET results/http

Aggregierte HTTP-Zeitmetriken je Task. Erzwingt den Task-Typ Http. Akzeptiert den Task-Filter plus:

Response: ein AggregatedHttpResults-Objekt; jeder taskResults-Eintrag meldet die Task-Referenz sowie die gemittelten Werte responseTime, dnsTime, headTime, dataTime (Millisekunden).

GET cr/httpResponseTime

HTTP-Antwortzeit-Reihen je Task. Akzeptiert den Task-Filter plus startDate, endDate und groupBy. Gibt ein reines Array von Serien-Objekten zurück:

[
  {
    "id": "ef10cd12-93f9-e311-bec5-dc85de1f0bc2",
    "rawUrl": "https://www.example.com",
    "name": "My website",
    "results": [ [1719181583, 142], [1719177983, 138] ]   // [unixSeconds, responseTimeMs], neueste zuerst
  }
]

Agenten

Agenten sind die geografisch verteilten Überwachungsstandorte. Die hier zurückgegebenen Pool-IDs sind die Werte, die Sie im Feld agentPools eines Tasks angeben.

GET agents

Listet Überwachungsagenten auf. Optionaler Query-Parameter:

Jeder Agent trägt id, upFrom, datacenter (Name/Stadt/Land/Bundesland), company (Name/URL), ip, version, lon/lat sowie pools.

[
  {
    "id": "a1b2c3d4-...-0001",
    "upFrom": "2024-06-20T08:00:00Z",
    "datacenter": { "name": "Example Hosting", "city": "Frankfurt", "country": "DE", "state": "" },
    "company": { "name": "Example Hosting", "url": "https://example-hosting.com" },
    "ip": "203.0.113.10",
    "version": "1.4.2",
    "lon": 8.68, "lat": 50.11,
    "pools": []
  }
]

GET agents/pools

Listet die öffentlichen Agent-Pools (geografische Regionen) auf. Jeder Pool trägt id, desc, seine agents, childPools und hidden. Verwenden Sie die id-Werte der Pools im Feld agentPools eines Tasks.

GET agents/ips anonym

Gibt die aktuellen IP-Adressen der Überwachungsagenten zurück — nützlich, um Host-Tracker in einer Firewall freizugeben. Dieser Endpunkt erfordert keine Authentifizierung. Standardmäßig liefert er text/plain, eine IP pro Zeile; senden Sie Accept: application/json, um stattdessen ein JSON-Array zu erhalten.

203.0.113.10
203.0.113.11
198.51.100.7

["203.0.113.10", "203.0.113.11", "198.51.100.7"]