account/monitors

Å opprette en monitor og den første baselinen er gratis. En syklus på 30 dager belastes så snart monitoren blir aktiv. Prisen avhenger av sjekkintervallet og dekker alle sjekker intervallet planlegger innenfor én syklus.

Et intervall mellom to trinn koster like mye som det neste, hyppigere trinnet: hver fjerde dag koster like mye som hver tredje dag.

Ekstra sjekker skjer hovedsakelig når du forkorter intervallet midt i en syklus. Hver vellykket ekstra sjekk koster beløpet i tabellen.

Etter 30 dager fornyes syklusen automatisk til prisen som da gjelder. Mislykkede sjekker koster ingenting. Når du setter på pause, arkiverer eller endrer intervallet, refunderer vi ingenting.

Hver konto kan ha opptil 50 monitorer samtidig, én per firma. Innen 24 timer kan du opprette opptil 50 monitorer; arkiverte teller også.

Prisen for et intervall får du gratis med GET /v1/account/monitoring/pricing, her for en sjekk hver sjuende dag:

1. Opprett. Du oppgir firmaet, sjekkintervallet og minst ett verifisert webhook-endepunkt. Monitoren starter med statusen initializing.
2. Baseline. Vi registrerer signalene fra de siste dagene som kjente. De leveres ikke, så du får bare det som er nytt etter det.
3. Aktiver. Vi belaster syklusen, monitoren blir active og sjekker for første gang med en gang.
4. Sjekk. Deretter sjekker den med det valgte intervallet. Hvert nytt signal utløser én melding per monitor til webhook-endepunktene dine.
5. Forny. Etter hver syklus belastes den neste automatisk, så lenge saldoen din dekker den.

Sjekkintervallet er mellom 1 og 30 dager. Det nøyaktige tidspunktet for en sjekk kan variere innenfor en time. Hver sjekk ser noen dager tilbake, så oppføringer som publiseres sent, kommer likevel frem.

En monitor leverer Signals-temaene i abonnementet ditt: fem i hver konto, Insolvenser med Pro, Omdannelser og M&A med Max. En webhook har det samme signalet i feltet data.signal som signals.

For monitorer på pause og feil forklarer status_reason hvorfor, for eksempel no_verified_endpoint eller insufficient_cycle_floor.

Alle stier ligger under /v1/account. Du leser og skriver med API-nøkkelen din i headeren x-api-key.

Hver skriveforespørsel trenger headeren Idempotency-Key, en unik verdi per operasjon, helst en UUID. Uten den svarer API-et med 428.

Gjentar du en forespørsel med samme nøkkel og samme data innen 24 timer, får du det lagrede svaret tilbake. Det har headeren Idempotency-Status: replayed. Slik oppretter ikke en nettverksfeil en monitor til.

Det gjelder også for feilsvar. For et nytt forsøk etter en rettelse bruker du derfor en ny nøkkel. Samme nøkkel med andre data gir 409.

Opptil 128 tegn er tillatt: bokstaver, sifre og . _ : -. Det første tegnet er en bokstav eller et siffer. En nøkkel i annet format gir 400.

Du trenger firmaets entity_id og minst ett verifisert webhook-endepunkt, se account/webhook-endpoints.

API-et svarer med 202: monitoren er opprettet, og baseline og aktivering kjører i bakgrunnen. meta.billing.charged_credits viser at ingenting ble belastet for dette.

GET /v1/account/monitors returnerer opptil 100 monitorer under monitors, med total. Arkiverte står ikke i listen.

GET /v1/account/monitors/{id} viser i tillegg den aktuelle syklusen i billing_cycle og de siste sjekkene i recent_runs.

PATCH /v1/account/monitors/{id} endrer sjekkintervallet. Den neste sjekken følger da med det nye intervallet, regnet fra endringen.

Den aktuelle syklusen beholder prisen og de inkluderte sjekkene. Den nye prisen gjelder fra neste syklus. Et kortere intervall kan utløse ekstra sjekker i den aktuelle syklusen.

POST …/{id}/pause stopper en aktiv monitor. Den betalte syklusen løper ut, og ingenting refunderes.

POST …/{id}/resume gjenopptar en monitor på pause eller en monitor med feil. Vi sjekker webhook-endepunkter, saldo og pris på nytt.

Innenfor den aktuelle betalte syklusen koster gjenopptakelse ingenting. Har syklusen løpt ut, starter en ny syklus nå til gjeldende pris. meta.request_credit_cost viser beløpet.

Mangler for eksempel et verifisert webhook-endepunkt, svarer API-et likevel med 200, men med meta.activated: false. Monitorens status og status_reason oppgir årsaken.

Har prisen endret seg, stopper en aktiv monitor ved slutten av syklusen med pricing_consent_required. Med resume godtar du den nye prisen.

DELETE …/{id} arkiverer monitoren for godt. Det er endelig og refunderer ingenting.

Feil har strukturen {"error": "…", "meta": {"message": "…"}}. I programmet ditt sjekker du verdien av error. Teksten i meta.message er på engelsk og kan endre seg. Feil koster ingenting.