Monitoreringsvarsler via API-et

Beta

Varselgrensesnittet i Connect API er merket som beta – feltnavn og strukturer kan fortsatt endres. Lås integrasjonen din til feltene som er dokumentert her, og forvent additive endringer.

Denne veiledningen er for utviklere som henter monitoreringsvarsler programmatisk gjennom Connect API – for eksempel for å mate eget saksbehandlingssystem eller egen risikomotor. For hva som genererer varsler og når, se Monitoreringssystemet; for arbeidsflyten i appen, se Jobbe med monitoreringsvarsler.

Modellen

Tre operasjoner dekker hele flyten:

Operasjon	Type	Formål
`alerts`	Query	List ut varsler, filtrert og paginert
`alertData`	Query	Hent den underliggende endringen bak et varsel
`alertUpdate`	Mutation	Løs (eller opphev løsning av) varsler etter id

Et varsel er en lettvektskonvolutt: noe endret seg på denne entiteten i dette datasettet. Konvolutten inneholder identitet, tidspunkt og status; det faktiske endringsinnholdet (før-/etter-verdier) ligger bak alertData.

Liste ut varsler

query {
  alerts(where: { states: [UNRESOLVED], kinds: [PEP, SANCTIONS], page: { limit: 50, offset: 0 } }) {
    edges {
      node {
        id
        kind # PEP | SANCTIONS | RELATIONS | COMPANY_INFORMATION
        state # UNRESOLVED | RESOLVED
        insertedAt
        computedAt
        resolvedBy
        resolvedAt
      }
    }
  }
}

Tilgjengelige filtre i where:

states — UNRESOLVED og/eller RESOLVED
kinds — de fire datasettypene: PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION
entity — alle varsler for én entitet-id
entityKind — standardverdi er COMPANY; angi eksplisitt hvis du monitorerer privatpersoner
period — et tidsvindu for når varslet ble opprettet
page — paginering med limit/offset

Hente hva som ble endret

query {
  alertData(alert: "<alert-id>") {
    # The change that triggered the alert, including before/after values.
    # The shape depends on the alert's dataset kind (a screening-hit change,
    # a relation change, or a company-information field change), and includes
    # settings context when the alert stems from a team-settings change.
  }
}

Bruk alertData etter behov (lazily) – hent det når systemet ditt faktisk behandler varslet, ikke under utlisting.

Løse varsler

mutation {
  alertUpdate(where: { ids: ["<alert-id-1>", "<alert-id-2>"], state: RESOLVED }) {
    ids
  }
}

De eneste statusene er UNRESOLVED og RESOLVED – det å markere som løst er reversibelt.
Løsning via API-et registreres i samme revisjonsspor som løsning i appen (resolvedBy, resolvedAt), og varsler du løser via API-et forsvinner også fra teamets kø i appen. Én løsningsmodell, to grensesnitt.
Det finnes ingen felter for ansvarlig eller kommentarer i Connect-varselgrensesnittet – tildeling skjer på entitetsnivå og administreres i appen.

Integrasjonsmønster

Den anbefalte flyten for synkronisering av varsler til ditt eget system:

Poll alerts(where: { states: [UNRESOLVED] }) etter en tidsplan som samsvarer med screening-frekvensen – selskaper screenes fem netter i uken, privatpersoner daglig, så polling oftere enn hver time gir ingen gevinst. Se screening-frekvens.
Avdupliser på varsel-id; bruk insertedAt for inkrementell henting.
Hent detaljer via alertData for varslene prosessen din faktisk håndterer.
Løs via alertUpdate så snart de er håndtert på din side, slik at begge systemer er samstemte om hva som gjenstår.

Hvis du foretrekker «push» fremfor polling, se Webhooks for hendelseslevering, og kombiner: webhook som trigger, alerts som sannhetskilde.

Synkronisere kundelisten din – få entiteter inn i monitorering via API-et
Innstillinger for monitoreringsvarsler – hvilke varselkategorier teamet ditt har aktivert (API-et returnerer kun varsler for aktiverte kategorier)
Ofte stilte spørsmål om API-et