Overvågningsalarmer via API'etKopiér link til overskriften

Denne vejledning er henvendt til udviklere, der anvender overvågningsalarmer programmatisk via Connect API – for eksempel til at føde jeres eget case-håndteringssystem eller risikomotor. For information om, hvad der genererer alarmer og hvornår, se Overvågningssystemet; for arbejdsgange i appen, se Arbejde med overvågningsalarmer.

ModellenKopiér link til overskriften

Tre operationer dækker hele flowet:

En alarm er en letvægtskuvert: noget ændrede sig på denne entitet i dette datasæt. Kuverten indeholder identitet, tidspunkt og status; det faktiske indhold af ændringen (før-/efter-værdier) findes bag alertData.

Oplistning af alarmerKopiér link 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
      }
    }
  }
}

Tilgængelige filtre i where:

• states — UNRESOLVED og/eller RESOLVED
• kinds: de fem datasættyper, PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION, CUSTOM_SCREENING_LISTS
• entity — alle alarmer for ét entitets-id
• entityKind — standardværdien er COMPANY; angiv den eksplicit, hvis du overvåger privatpersoner
• period — et tidsvindue for oprettelse af alarmer
• page — limit/offset-paginering

Hentning af ændringenKopiér link 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.
  }
}

Brug alertData efter behov (lazily) — hent det, når dit system rent faktisk behandler alarmen, ikke under oplistningen.

Håndtering af alarmerKopiér link til overskriften

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

• De eneste tilstande er UNRESOLVED og RESOLVED — håndtering er reversibel.
• Håndtering via API'et registreres i det samme revisionsspor som håndtering i appen (resolvedBy, resolvedAt), og alarmer, du håndterer via API'et, forsvinder også fra dit teams kø i appen. Én håndteringsmodel, to grænseflader.
• Der er intet felt til ansvarlig eller kommentar på Connect-alarmfladen — tildeling af ansvarlig sker på entitetsniveau og administreres i appen.

IntegrationsmønsterKopiér link til overskriften

Det anbefalede flow til synkronisering af alarmer til dit eget system:

1. Foretag polling af alerts(where: { states: [UNRESOLVED] }) i en tidsplan, der matcher screeningkadencen — virksomheder screenes fem nætter om ugen, privatpersoner dagligt, så polling oftere end én gang i timen giver ingen fordel. Se screeningkadence.
2. Dedupliker på alarmens id; brug insertedAt til trinvis hentning.
3. Hent detaljer via alertData for de alarmer, din proces rent faktisk håndterer.
4. Håndter via alertUpdate, når den er behandlet på din side, så begge systemer er enige om, hvad der udestår.

WebhooksKopiér link til overskriften

Tilmeld dig monitoring.alert.created-webhooken for at modtage nye alarmer uden polling. Strise sender den én gang for hver ny alarm, så snart alarmen er tilgængelig i alerts. Nyttelasten indeholder alarmens alertId, entityId, entityKind, kind, computedAt og insertedAt. alerts returnerer de samme felter for en ny alarm. Gå direkte til trin 3, og kald 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"
  }
}

Kuverten omkring data er ens for alle hændelser; se Hvad du modtager.

Brug webhooken som udløser og alerts som sandhedskilde:

• Webhooken rapporterer kun, at en alarm blev oprettet. Den rapporterer ikke, at nogen har håndteret alarmen i appen eller via API'et. For at få den aktuelle state skal du filtrere alerts på entity, entityKind og kinds. entityKind er som standard COMPANY, så angiv den for alarmer vedrørende privatpersoner.
• Behold et periodisk opslag mod alerts som fallback, så du stadig opfanger en alarm, hvis levering dit slutpunkt aldrig kvitterede for. Dedupliker på alarm-id'et: alertId i webhook-nyttelasten, id i alerts.

Relaterede siderKopiér link til overskriften

• Synkronisering af din kundeliste — få entiteter ind i overvågning via API'et
• Indstillinger for overvågningsalarmer — hvilke alarmkategorier dit team har aktiveret (API'et returnerer kun alarmer for aktiverede kategorier)
• API-FAQ