Overvågningsadvarsler via API

Beta

Advarselsgrænsefladen i Connect API er markeret som Beta — feltnavne og strukturer kan stadig ændre sig. Lås din integration til de felter, der er dokumenteret her, og forvent additive udvidelser.

Denne vejledning er henvendt til udviklere, der anvender overvågningsadvarsler programmatisk via Connect API – for eksempel til at forsyne jeres eget sagshåndteringssystem eller risikomotor. For information om, hvad der genererer advarsler og hvornår, se Overvågningssystemet; for arbejdsgangen i appen, se Arbejde med overvågningsadvarsler.

Modellen

Tre operationer dækker hele kredsløbet:

Operation	Type	Formål
`alerts`	Query	Oplist advarsler, filtreret og pagineret
`alertData`	Query	Hent den underliggende ændring bag én advarsel
`alertUpdate`	Mutation	Løs (eller genåbn) advarsler efter id

En advarsel er en letvægtskuvert: noget ændrede sig for denne Entitet i dette datasæt. Kuverten indeholder identitet, tidsangivelser og Status; det faktiske ændringsindhold (før/efter-værdier) findes bag alertData.

Oplistning af advarsler

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
      }
    }
  }
}

Tilgængelige filtre i where:

states — UNRESOLVED og/eller RESOLVED
kinds — de fire datasættyper: PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION
entity — alle advarsler for ét Entitet-id
entityKind — standard er COMPANY; angiv eksplicit, hvis du udfører Overvågning af privatpersoner
period — et tidsvindue for oprettelse af advarsler
page — limit/offset-paginering

Hent hvad der ændrede sig

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

Brug alertData lazily — hent det, når dit system rent faktisk behandler advarslen, ikke under oplistningen.

Løsning af advarsler

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

De eneste mulige værdier for Status er UNRESOLVED og RESOLVED — løsning er reversibel.
Løsning via API'et registreres i samme revisionsspor som løsning i appen (resolvedBy, resolvedAt), og advarsler, du løser via API'et, forsvinder også fra dit Teams kø i appen. Én løsningsmodel, to grænseflader.
Der er intet felt til Ansvarlig eller kommentarer på advarselsfladen i Connect API — tildeling af Ansvarlig sker på Entitet-niveau og administreres i appen.

Integrationsmønster

Det anbefalede forløb til synkronisering af advarsler til dit eget system:

Poll alerts(where: { states: [UNRESOLVED] }) efter en tidsplan, der matcher kadencen for Screening — Virksomheder screenes fem nætter om ugen, privatpersoner dagligt, så det giver ingen fordel at foretage polling oftere end én gang i timen. Se kadence for Screening.
Dedupliker på advarsels-id; brug insertedAt til trinvis hentning.
Hent detaljer via alertData for de advarsler, din proces rent faktisk behandler.
Løs via alertUpdate, når advarslen er håndteret på din side, så begge systemer er enige om, hvad der udestår.

Hvis du foretrækker push frem for poll, se Webhooks for hændelseslevering, og kombiner: Webhook som udløser, alerts som den primære sandhedskilde.

Synkronisering af din kundeliste — få entiteter ind i Overvågning via API'et
Indstillinger for overvågningsadvarsler — hvilke advarselskategorier dit Team har aktiveret (API'et returnerer kun advarsler for aktiverede kategorier)
API FAQ