Monitoreringsvarsler via API-etKopier lenke til overskriften

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

ModellenKopier lenke til overskriften

Tre operasjoner dekker hele flyten:

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 varslerKopier lenke til overskriften

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

Tilgjengelige filtre i where:

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

Hente hva som ble endretKopier lenke til overskriften

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 lazy – hent det når systemet ditt faktisk behandler varselet, ikke under listing.

Løse varslerKopier lenke til overskriften

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

• De eneste statusene er UNRESOLVED og RESOLVED – å løse et varsel 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 er ingen felt for ansvarlig eller kommentarer på varslingsgrensesnittet i Connect – tildeling skjer på entitetsnivå og administreres i appen.

IntegrasjonsmønsterKopier lenke til overskriften

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

1. Poll alerts(where: { states: [UNRESOLVED] }) etter en tidsplan som samsvarer med screening-frekvensen – selskaper screenes fem netter i uken, privatpersoner daglig, så å polle oftere enn en gang i timen gir ingen gevinst. Se screening-frekvens.
2. Dedupliser på varsel-id; bruk insertedAt for inkrementell henting.
3. Hent detaljer via alertData for varslene prosessen din faktisk håndterer.
4. Løs via alertUpdate når det er håndtert på din side, slik at begge systemer er samkjørte om hva som gjenstår.

WebhooksKopier lenke til overskriften

For å motta nye varsler uten polling, abonner på monitoring.alert.created-webhooken. Strise sender den én gang for hvert nye varsel, så snart varselet er tilgjengelig i alerts. Nyttelasten inneholder varselets alertId, entityId, entityKind, kind, computedAt og insertedAt. alerts returnerer de samme feltene for et nytt varsel. Gå rett til steg 3 og kall alertData(alert: "<alertId>").

{
  "eventType": "monitoring.alert.created",
  "data": {
    "alertId": "…",
    "entityId": "…",
    "entityKind": "Company",
    "kind": "PEP",
    "computedAt": "2026-10-12T04:12:09.512331",
    "insertedAt": "2026-10-12T07:30:41.104857"
  }
}

Konvolutten rundt data er lik for alle hendelser; se Hva du mottar.

Bruk webhooken som trigger og alerts som sannhetskilde:

• Webhooken varsler kun om at et varsel ble opprettet. Den rapporterer ikke at noen løste varselet i appen eller via API-et. For å hente gjeldende state, filtrer alerts på entity, entityKind og kinds. entityKind har COMPANY som standardverdi, så sett denne for varsler om privatpersoner.
• Behold en periodisk polling av alerts som en reserve, slik at du likevel fanger opp varsler der endepunktet ditt aldri kvitterte for leveringen. Dedupliser på varsel-id: alertId i webhook-nyttelasten, id i alerts.

Relaterte siderKopier lenke til overskriften

• 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