account/monitors

Utworzenie monitora i pierwszy stan bazowy są bezpłatne. Cykl 30 dni jest naliczany, gdy tylko monitor staje się aktywny. Cena zależy od częstotliwości sprawdzania i obejmuje wszystkie sprawdzenia, które częstotliwość przewiduje w jednym cyklu.

Częstotliwość między dwoma stopniami kosztuje tyle co najbliższy częstszy stopień: co cztery dni kosztuje tyle co co trzy dni.

Dodatkowe sprawdzenia zdarzają się głównie wtedy, gdy skrócisz odstęp w trakcie cyklu. Każde udane dodatkowe sprawdzenie kosztuje kwotę z tabeli.

Po 30 dniach cykl odnawia się automatycznie po cenie obowiązującej w tym momencie. Nieudane sprawdzenia nic nie kosztują. Przy wstrzymaniu, archiwizacji lub zmianie odstępu niczego nie zwracamy.

Każde konto może mieć jednocześnie do 50 monitorów, jeden na firmę. W ciągu 24 godzin możesz utworzyć do 50 monitorów; zarchiwizowane też się liczą.

Cenę danej częstotliwości dostajesz bezpłatnie przez GET /v1/account/monitoring/pricing, tutaj dla sprawdzenia co siedem dni:

1. Utworzenie. Podajesz firmę, częstotliwość sprawdzania i co najmniej jeden zweryfikowany endpoint webhooka. Monitor startuje ze statusem initializing.
2. Stan bazowy. Sygnały z ostatnich kilku dni zapisujemy jako znane. Nie są dostarczane, więc dostajesz tylko to, co nowe po tym momencie.
3. Aktywacja. Naliczamy cykl, monitor staje się active i od razu sprawdza po raz pierwszy.
4. Sprawdzanie. Potem sprawdza w wybranym odstępie. Każdy nowy sygnał wywołuje jedną wiadomość na monitor do twoich endpointów webhooków.
5. Odnowienie. Po każdym cyklu następny jest naliczany automatycznie, dopóki saldo go pokrywa.

Częstotliwość sprawdzania wynosi od 1 do 30 dni. Dokładna chwila sprawdzenia może się wahać w ramach godziny. Każde sprawdzenie patrzy kilka dni wstecz, więc wpisy opublikowane z opóźnieniem też docierają.

Monitor dostarcza tematy Signals twojego planu: pięć na każdym koncie, Niewypłacalności w Pro, Przekształcenia i M&A w Max. Webhook niesie w polu data.signal ten sam sygnał co signals.

Dla wstrzymanych monitorów i błędów status_reason wyjaśnia powód, np. no_verified_endpoint lub insufficient_cycle_floor.

Wszystkie ścieżki są pod /v1/account. Czytasz i zapisujesz kluczem API w nagłówku x-api-key.

Każde zapytanie zapisujące wymaga nagłówka Idempotency-Key, unikalnej wartości na operację, najlepiej UUID. Bez niego API odpowiada 428.

Jeśli powtórzysz zapytanie z tym samym kluczem i tymi samymi danymi w ciągu 24 godzin, dostajesz z powrotem zapisaną odpowiedź. Ma ona nagłówek Idempotency-Status: replayed. Dzięki temu błąd sieci nie tworzy drugiego monitora.

Dotyczy to też odpowiedzi z błędem. Do nowej próby po poprawce użyj więc nowego klucza. Ten sam klucz z innymi danymi zwraca 409.

Dozwolone do 128 znaków: litery, cyfry i . _ : -. Pierwszy znak to litera lub cyfra. Klucz w innym formacie zwraca 400.

Potrzebujesz entity_id firmy i co najmniej jednego zweryfikowanego endpointu webhooka, zobacz account/webhook-endpoints.

API odpowiada 202: monitor jest utworzony, a stan bazowy i aktywacja działają w tle. meta.billing.charged_credits pokazuje, że nic za to nie naliczono.

GET /v1/account/monitors zwraca do 100 monitorów w monitors, z total. Zarchiwizowanych nie ma na liście.

GET /v1/account/monitors/{id} pokazuje też bieżący cykl w billing_cycle i ostatnie sprawdzenia w recent_runs.

PATCH /v1/account/monitors/{id} zmienia częstotliwość sprawdzania. Następne sprawdzenie nastąpi wtedy w nowym odstępie, liczonym od zmiany.

Bieżący cykl zachowuje cenę i wliczone sprawdzenia. Nowa cena obowiązuje od następnego cyklu. Krótszy odstęp może wywołać dodatkowe sprawdzenia w bieżącym cyklu.

POST …/{id}/pause zatrzymuje aktywny monitor. Opłacony cykl biegnie do końca, nic nie jest zwracane.

POST …/{id}/resume wznawia wstrzymany monitor lub monitor z błędem. Ponownie sprawdzamy endpointy webhooków, saldo i cenę.

W ramach bieżącego opłaconego cyklu wznowienie nic nie kosztuje. Jeśli cykl się skończył, teraz zaczyna się nowy cykl po aktualnej cenie. meta.request_credit_cost pokazuje kwotę.

Jeśli np. brakuje zweryfikowanego endpointu webhooka, API mimo to odpowiada 200, ale z meta.activated: false. Status monitora i status_reason podają powód.

Jeśli cena się zmieniła, aktywny monitor zatrzymuje się na końcu cyklu z pricing_consent_required. Przez resume akceptujesz nową cenę.

DELETE …/{id} archiwizuje monitor na stałe. To ostateczne i nic nie jest zwracane.

Błędy mają strukturę {"error": "…", "meta": {"message": "…"}}. W programie sprawdzaj wartość error. Tekst w meta.message jest po angielsku i może się zmieniać. Błędy nic nie kosztują.