Brak pasujących sekcji.

Host-Tracker REST API v1

Stabilne API HTTP uwierzytelniane tokenem, służące do zarządzania zadaniami monitorowania stron internetowych, kontaktami, subskrypcjami alertów/raportów oraz do odczytu statystyk, przestojów i incydentów.

Adres bazowy

Każda ścieżka w tym dokumencie jest podana względem adresu bazowego. Ten sam interfejs API obsługują dwa punkty dostępu:

W tym dokumencie zapis wywołania w postaci GET tasks oznacza GET BASE_URL/tasks — np. https://api1.host-tracker.com/tasks lub https://www.host-tracker.com/api/web/v1/tasks.

Typ treści i metody HTTP

Domyślnie żądania i odpowiedzi mają typ application/json (informacje o XML znajdziesz w sekcji Konwencje). API wykorzystuje standardowe metody HTTP:

• GET — odczyt encji (zadania, kontakty, subskrypcje, statystyki, przestoje, incydenty, agenci).
• POST — utworzenie encji lub uruchomienie akcji.
• PUT — aktualizacja istniejących encji.
• DELETE — usunięcie encji.
• PATCH — aktualizacje częściowe (używane do ponownego wysłania kodu potwierdzającego kontakt).

Zastępowanie metody HTTP

Jeśli Twój klient nie może wysyłać żądań PUT, DELETE ani PATCH, wyślij POST i dodaj nagłówek X-HTTP-Method-Override wskazujący zamierzoną metodę. Na przykład, aby zaktualizować zadania, wykonaj POST do tasks z nagłówkiem X-HTTP-Method-Override: PUT.

Konwencje

Serializacja JSON

JSON używa nazw właściwości w formacie camelCase. Pola o wartości null są pomijane w odpowiedziach (puste tablice są nadal zwracane jako []). Kolejność właściwości jest stała: najpierw identyfikator i adres/URL, następnie pola dziedziczone, a na końcu pola specyficzne dla typu.

Data i czas

Odpowiedzi tworzenia/odczytu zadań zawierają znaczniki czasu jako ciągi ISO-8601 UTC (np. 2024-06-21T22:26:23Z). Punkty końcowe statystyk, przestojów, incydentów i wyników dodatkowo stosują podwójną reprezentację: każdy czas występuje zarówno jako pole liczbowe w sekundach Unix (z sufiksem Unix), jak i jako ciąg czytelny dla człowieka, sformatowany zgodnie z formatem daty i strefą czasową profilu konta. Filtry żądań akceptują sekundy Unix i/lub sformatowane ciągi, w zależności od punktu końcowego (opisane przy każdym punkcie końcowym poniżej). Wszystkie znaczniki czasu Unix to liczba sekund od 1970-01-01T00:00:00Z.

Negocjacja treści XML

Wszystkie punkty końcowe mogą również zwracać XML. Wyślij nagłówek Accept: application/xml, aby otrzymać treść XML zamiast JSON; odpowiedź wykorzystuje klasyczną reprezentację tego samego grafu obiektów generowaną przez .NET-owy XmlSerializer. Format JSON jest domyślny i zalecany.

CORS

Żądania cross-origin są dozwolone. Zwykłe żądania (bez poświadczeń) są akceptowane z dowolnego źródła (Access-Control-Allow-Origin: *). Żądania wysyłające pliki cookie/poświadczenia są akceptowane wyłącznie ze źródeł *.host-tracker.com. Klienci korzystający z tokenu (za pomocą nagłówka Authorization, jak opisano w tym dokumencie) nie podlegają ograniczeniu dotyczącemu źródeł z poświadczeniami.

Uwierzytelnianie

Każdy punkt końcowy oprócz POST users/token oraz anonimowych punktów końcowych listy agentów wymaga uwierzytelnienia. Akceptowane są dwa schematy:

• Token bearer — uzyskiwany z POST users/token, wysyłany jako Authorization: bearer <token>. Jest to podstawowy schemat.
• HTTP Basic — Authorization: Basic <base64(login:password)>. Poświadczenia są dekodowane jako ISO-8859-1. Wygodny do szybkich testów; do automatyzacji zalecany jest token bearer.

POST users/token anonimowy

Wymień login i hasło na token bearer. Token jest ważny przez 48 godzin.

Treść żądania

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

Odpowiedź — 200 OK

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

W przypadku niepowodzenia odpowiedź ma status 401 z kodem maszynowym IncorrectLoginOrPassword (lub AccessDenied, jeśli dostęp do API jest wyłączony dla danego konta) oraz nagłówkiem WWW-Authenticate: Bearer.

Używanie tokenu

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

Personifikacja subkonta (forLogin)

Jeśli konto nadrzędne przyznało Twojemu subkontu dostęp do swoich danych, zaloguj się jako subkonto, ale przekaż login konta nadrzędnego w polu forLogin. Zwrócony token pozwala wtedy zarządzać kontem nadrzędnym dokładnie tak, jakby punkty końcowe były wywoływane dla własnego konta, z zastrzeżeniem uprawnień przyznanych przez konto nadrzędne. Na przykład, jeśli przyznano jedynie dostęp do odczytu zadań monitorowania, wywołania GET się powiodą, ale POST/PUT/PATCH/DELETE na zadaniach zostaną odrzucone.

# 1. Uzyskaj token personifikacji
POST BASE_URL/users/token HTTP/1.1
Content-Type: application/json

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

# 2. Użyj zwróconego ticketu, aby odczytać zadania KONTA NADRZĘDNEGO
GET BASE_URL/tasks HTTP/1.1
Authorization: bearer <ticket from step 1>

curl

# fetch a token and store it
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)

# call an authenticated endpoint
curl -s https://api1.host-tracker.com/tasks \
  -H "Authorization: bearer $TOKEN"

Błędy i kody maszynowe

Błędy zwracają standardowy kod statusu HTTP wraz z krótkim kodem odczytywalnym maszynowo, na podstawie którego Twoja integracja może podejmować decyzje. Treść odpowiedzi to zwykły angielski opis tekstowy (nie JSON), przeznaczony dla ludzi/logów.

Kod maszynowy jest dostarczany na dwa sposoby:

• Nagłówek odpowiedzi X-HT-Reason — zawiera kod w każdej odpowiedzi i przy każdej wersji HTTP. To zalecany sposób wykrywania typu błędu.
• Fraza powodu HTTP/1.1 (reason phrase) — wiersz statusu wygląda np. tak: HTTP/1.1 400 SimilarExists. Zachowana dla zgodności wstecznej, ale należy pamiętać, że HTTP/2 i HTTP/3 usunęły frazy powodu z protokołu, więc to pole może być puste, gdy połączenie negocjuje HTTP/2+. Preferuj nagłówek X-HT-Reason.

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

Same task allready exists

Słownik kodów błędów

Wszystkie kody maszynowe, jakie może zwrócić API, pogrupowane według obszaru, wraz z typowym statusem HTTP. O ile nie zaznaczono inaczej, błędy mają status 400 Bad Request.

Uwierzytelnianie

Zadania

Kontakty

Subskrypcje

Limity zapytań

Żądania są limitowane per klient, per punkt końcowy. Przekroczenie limitu skutkuje odpowiedzią 429 z kodem maszynowym RequestThrottled i nagłówkiem Retry-After (w sekundach).

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."

Zadania monitorowania

GET tasks/types

Zwraca tablicę nazw typów zadań znanych systemowi:

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

GET tasks/intervals

Zwraca tablicę interwałów monitorowania (w minutach) akceptowanych dla Twojego konta, np. [1,5,15,30,60]. Użyj jednej z tych wartości w polu interval podczas tworzenia zadania; każda inna wartość skutkuje błędem WrongInterval.

GET tasks

Lista zadań monitorowania. Wszystkie parametry zapytania są opcjonalne; bez żadnego parametru zwracane są wszystkie zadania konta. Aby przekazać tablicę, powtórz parametr, np. ?ids=guid1&ids=guid2.

Parametr info

Umożliwia zażądanie dodatkowych danych osadzonych w każdym zadaniu. Połącz wartości przecinkami (?info=stats,subscriptions) lub podaj równoważną liczbę całkowitą maski bitowej:

?info=stats,subscriptions,results jest równoważne ?info=7.

Parametry filtrowania

Odpowiedź — 200 OK

Tablica obiektów zadań. Dokładny zestaw pól zależy od typu zadania; wspólna baza obejmuje id, name, taskType, enabled, interval, lastState, creationTime, tags, agentPools, a także (gdy zażądano przez info) subscriptions, stats, results i attached. Gdy dołączone są wyniki, każdy wynik zawiera co najmniej timestamp (sekundy Unix UTC) i eventNumber; pozostałe pola są specyficzne dla typu zadania (zobacz odpowiedź tworzenia poniżej, dla kształtu HTTP).

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

GET tasks/{id:guid}

Pobiera pojedyncze zadanie po identyfikatorze. Akceptuje ten sam parametr info (oraz sdtu/edtu, gdy info=results). Zwraca obiekt zadania lub 404 NotFound, jeśli nie istnieje.

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

Tworzy zadanie monitorowania podanego typu. W przypadku powodzenia zwraca 201 Created, względny nagłówek Location: /tasks/{id} oraz pełny obiekt utworzonego zadania.

Treść żądania — zadanie HTTP

{
  // Pola specyficzne dla HTTP
  "url": "https://www.example.com",        // WYMAGANE
  "httpMethod": "Get",                       // Get | Post | Head (domyślnie Get)
  "userAgent": "MyMonitor",
  "referer": "https://www.google.com",
  "acceptHeader": "application/json",
  "followRedirect": false,
  "treat300AsError": false,                // jeśli ustawione, followRedirect jest ignorowane
  "checkDnsbl": false,                       // sprawdza domenę względem list blokad DNS
  "checkDomainExpiration": false,            // monitoruje wygaśnięcie domeny (tylko prawidłowe domeny)
  "checkCertificateExpiration": false,       // monitoruje wygaśnięcie certyfikatu TLS (tylko https)
  "checkRussianBlackLists": false,
  "checkWebRisk": false,
  "timeout": 40000,                          // ms przed uznaniem sprawdzenia za nieudane
  "keywords": ["error", "maintenance"],
  "keywordMode": "ReverseAny",             // patrz tryby słów kluczowych poniżej
  "userName": "basic-auth-user",          // dane uwierzytelniające dla monitorowanego zasobu
  "password": "basic-auth-pass",
  "postParameters": "a=1\r\nb=2",          // tylko z httpMethod=Post
  "ignoredStatuses": [404, 500],

  // pola wspólne dla każdego typu zadania
  "interval": 5,                             // minuty; musi być akceptowanym interwałem
  "enabled": true,
  "fullLog": false,                          // tylko pakiety zaawansowane
  "openStat": true,
  "name": "My website",
  "tags": ["production", "web"],
  "agentPools": ["westeurope", "asia"],  // patrz uwagi poniżej
  "subscriptions": [ /* subskrypcje osadzone, patrz poniżej */ ]
}

Subskrypcje osadzone

Tablica subscriptions subskrybuje kontakty do alertów/raportów tego zadania już w momencie tworzenia. Każdy wpis używa kształtu subskrypcji; nie ustawiaj taskIds (jest ono ustalone na nowe zadanie). Jeśli pominięto contactIds, subskrybowane są wszystkie Twoje potwierdzone kontakty. Subskrypcje raportów są stosowane wyłącznie do kontaktów Email.

Pozostałe typy zadań

• tasks/ping — treść zawiera pole host oraz pola wspólne.
• tasks/port — treść zawiera pola host i port oraz pola wspólne.
• tasks/rusbl — sprawdzenie listy blokad rosyjskiego rejestru; treść zawiera url, oraz ignoreWarnings, doNotSendMsgOnWarnings, prefixMatch i pola wspólne.

Odpowiedź — 201 Created (zadanie HTTP)

{
  "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 & warianty typowane

Aktualizacja zadań. Dwie formy:

• Po identyfikatorze — PUT tasks/{id} (tylko pola wspólne) lub typowane PUT tasks/http/{id}, tasks/ping/{id}, tasks/port/{id}, tasks/rusbl/{id} (również pola specyficzne dla typu). Treść ma taki sam edytowalny kształt jak przy tworzeniu; zmieniane są tylko pola, które podasz.
• Po filtrze — PUT tasks?<filter> (tylko pola wspólne) lub typowane PUT tasks/{type}?<filter> (co ogranicza filtr do tego typu). Wykorzystuje te same parametry filtrowania co GET tasks. Zwraca zaktualizowane zadanie(a).

Nietypowane PUT tasks / PUT tasks/{id} może zmieniać wyłącznie pola wspólne dla wszystkich typów zadań — aby zmienić ustawienia specyficzne dla typu, użyj typowanego punktu końcowego.

DELETE tasks/{id:guid} & tasks

• DELETE tasks/{id} — usuwa pojedyncze zadanie; zwraca usunięte zadanie.
• DELETE tasks?<filter> — zbiorcze usuwanie według filtra zadań (filtr można też podać w treści żądania). Zwraca usunięte zadania.

POST tasks/$batch · task/$batch

Uruchamia kilka operacji na zadaniach w jednym żądaniu. Treść to tablica JSON pod-żądań; odpowiedź to tablica JSON pod-odpowiedzi w tej samej kolejności. Pod-operacja jest wybierana na podstawie ostatniego segmentu pola relativeUrl (np. http → POST tasks/http). Treść żądania musi być w formacie JSON (Content-Type: application/json). Ten sam mechanizm istnieje dla kontaktów pod adresami 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... }" }
]

Kontakty

Kontakty to adresaci otrzymujący alerty i raporty (adresy e-mail, numery telefonów do SMS/połączeń głosowych). Identyfikatory kontaktów są używane przy tworzeniu subskrypcji.

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

Statyczne wyliczenia używane przez punkty końcowe kontaktów:

GET contacts & contacts/{id:guid}

Lista kontaktów (opcjonalnie filtrowana) lub pobranie jednego po identyfikatorze. Dodaj ?info=subscriptions, aby osadzić subskrypcje każdego kontaktu. Bez filtra zwracane są wszystkie kontakty konta.

Obiekt kontaktu

Pola wspólne: id, confirmed, contactType, name, address, alertDelay, activePeriodStart/activePeriodEnd (HH:mm), activeDays, sendCost. Kontakty Email dodają reportFormat (Text/ShortText), sendNews, sendBillingNotifications; kontakty SMS/IM dodają gateway.

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

Tworzy kontakt. Zwraca 201 Created, względny nagłówek Location: /contacts/{id} oraz ContactOperationResult ({ contact, status }), którego pole status informuje o wyniku potwierdzenia.

{
  "address": "ops@@example.com",          // WYMAGANE
  "name": "Ops mailbox",
  "alertDelay": 0,                        // minuty; jedna z wartości contacts/delays
  "reportFormat": "Text",               // Text | ShortText (tylko email)
  "activePeriodStart": "00:00",        // opcjonalne okno ciszy (HH:mm)
  "activePeriodEnd": "23:59",
  "activeDays": ["Monday", "Tuesday"],   // opcjonalne; domyślnie wszystkie dni
  "subscriptions": [ /* opcjonalne subskrypcje osadzone */ ]
}

Kontakty SMS i głosowe domyślnie korzystają z bramek twiliosms / twiliovoice, otrzymują domyślną cenę za wiadomość i przechowują numer z wiodącym +. Zmiana adresu lub bramki kontaktu resetuje jego stan potwierdzenia.

Wartości statusu potwierdzenia

Pole status wyniku informuje o rezultacie wysłania kodu potwierdzającego:

PUT contacts & warianty typowane

• Po identyfikatorze — PUT contacts/{id} (pola wspólne) lub typowane PUT contacts/email/{id}, contacts/sms/{id}, contacts/voice/{id}. Zmieniane są tylko pola, które wyślesz.
• Po filtrze — PUT contacts?<filter> lub typowane PUT contacts/{type}?<filter> (ogranicza filtr do tego typu), wykorzystując filtr kontaktów.

PUT contacts/im (obie formy) zwraca 400 WrongContactType.

DELETE contacts/{id:guid} & contacts

Usuwa jeden kontakt po identyfikatorze lub wykonuje zbiorcze usuwanie według filtra kontaktów. Podobnie jak w przypadku zadań, zbiorcze usunięcie z pustym filtrem jest odrzucane z kodem 400 EmptyFilter.

Kody potwierdzające

Niepotwierdzone kontakty muszą potwierdzić własność krótkim kodem dostarczonym na adres kontaktu.

• PATCH contacts/{id}/code — (ponownie) generuje i wysyła kod potwierdzający. Zwraca ContactOperationResult ze statusem takim jak CodeSent.
• POST contacts/{id}/code — potwierdza kontakt poprzez przesłanie kodu. Treść: { "code": "12345" }. Po powodzeniu kontakt staje się potwierdzony.

Alerty i subskrypcje

Subskrypcja łączy jedno lub więcej zadań i kontaktów z zestawem typów alertów i/lub raportów. Pojedynczy wpis subskrypcji tworzy iloczyn kartezjański swoich zadań i kontaktów, generując jeden alert/raport na każdą kombinację (zadanie, kontakt, typ).

Kształt subskrypcji

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

• Wymagane jest co najmniej jedno z alertTypes / reportTypes, w przeciwnym razie zwracany jest błąd AlertsAndReportsAreEmpty.
• Pominięcie taskIds domyślnie oznacza wszystkie Twoje zadania; pominięcie contactIds domyślnie oznacza wszystkie Twoje kontakty. Jawnie podana pusta tablica oznacza „żadne”.
• Subskrypcje raportów dotyczą wyłącznie kontaktów Email — typy raportów na kontaktach innych niż Email są po cichu ignorowane (ich subskrypcje alertów są nadal tworzone).
• Identyfikatory, których nie jesteś właścicielem, są ignorowane.

GET subscriptions/alertTypes · subscriptions/reportTypes

GET subscriptions

Lista subskrypcji. Zwraca jeden wpis na każdą dopasowaną subskrypcję alertu lub raportu (nigdy nie scalane). Opcjonalne filtry:

POST subscriptions · DELETE subscriptions

Obie metody przyjmują w treści tablicę JSON wpisów subskrypcji. POST dodaje opisane subskrypcje (wstawiane są tylko nowe wiersze); DELETE usuwa te, które istnieją. Obie zwracają 200 OK z pustą treścią. Nieznane typy alertów/raportów są odrzucane z błędem UnknownAlertType / UnknownReportType.

[
  { "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>"]}]'

Statystyki i wyniki

GET stats

Zagregowane dane uptime/downtime dla każdego zadania w oknie czasowym. Akceptuje filtr zadań do wyboru zadań, a także:

Odpowiedź

Obiekt Stats z rozwiązanym oknem czasowym (podwójne pola daty) i tablicą stats. Każdy wpis zawiera referencję do zadania oraz: uptimeInMinutes/uptimeSpan, downtimeInMinutes/downtimeSpan, czasy dostępności/niedostępności w oknach konserwacji, totalTimeInMinutes, liczniki sprawdzeń w poszczególnych przedziałach oraz uptimePercent/downtimePercent.

GET outages

Przedziały czasu niedostępności dla każdego zadania. Akceptuje filtr zadań a także:

Odpowiedź: obiekt Outages z rozwiązanym oknem czasowym i tablicą taskOutages; każdy element łączy zadanie z jego przedziałami outages (startTime/endTime + warianty Unix, numery zdarzeń, opcjonalny komentarz).

GET incident

Lista incydentów (zdarzeń błędu) dla każdego zadania. Akceptuje filtr zadań oraz te same parametry okna/strefy czasowej co outages, a także:

Odpowiedź: obiekt Incidents z tablicą taskIncidents. Każdy incydent zawiera taskId, checkId, czasy Unix początku/końca, błędną location, error, hasSnapshot oraz (z fullLog) blok recheck wymieniający lokalizacje OK oraz lokalizacje błędne dla każdego błędu.

GET incident/snapshot

Pobiera zapisany zrzut odpowiedzi przechwycony dla incydentu. Parametry:

Zwraca zrzut (znacznik czasu wraz z przechwyconymi bajtami), jeśli istnieje, lub null, jeśli dla danego incydentu nie ma zrzutu.

GET results/http

Zagregowane metryki czasowe HTTP dla każdego zadania. Wymusza typ zadania Http. Akceptuje filtr zadań, a także:

Odpowiedź: obiekt AggregatedHttpResults; każdy wpis taskResults zawiera referencję do zadania oraz uśrednione responseTime, dnsTime, headTime, dataTime (w milisekundach).

GET cr/httpResponseTime

Szereg czasowy czasu odpowiedzi HTTP dla każdego zadania. Akceptuje filtr zadań oraz startDate, endDate i groupBy. Zwraca zwykłą tablicę obiektów szeregu:

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

Agenci

Agenci to geograficznie rozproszone lokalizacje monitorowania. Identyfikatory puli zwracane tutaj to wartości przekazywane w polu agentPools zadania.

GET agents

Lista agentów monitorujących. Opcjonalny parametr zapytania:

Każdy agent zawiera id, upFrom, datacenter (name/city/country/state), company (name/url), ip, version, lon/lat oraz 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

Lista publicznych puli agentów (regionów geograficznych). Każda pula zawiera id, desc, swoich agents, childPools oraz hidden. Użyj wartości id puli w polu agentPools zadania.

GET agents/ips anonimowy

Zwraca aktualne adresy IP agentów monitorujących — przydatne do umieszczania Host-Tracker na białej liście w zaporze sieciowej (firewall). Ten punkt końcowy nie wymaga uwierzytelnienia. Domyślnie zwraca text/plain, jeden adres IP na wiersz; wyślij Accept: application/json, aby zamiast tego otrzymać tablicę JSON.

203.0.113.10
203.0.113.11
198.51.100.7

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