Övervakningsaviseringar via API:etKopiera länk till rubriken

Den här guiden är till för utvecklare som konsumerar övervakningsaviseringar programmatiskt via Connect API – till exempel för att mata ert eget ärendehanteringssystem eller er riskmotor. För vad som genererar aviseringar och när, se Övervakningssystemet; för arbetsflödet i appen, se Arbeta med övervakningsaviseringar.

ModellenKopiera länk till rubriken

Tre operationer täcker hela flödet:

En avisering är ett lättviktskuvert: någonting ändrades på denna Entitet i detta dataset. Kuvertet bär identitet, tidpunkt och Status; själva ändringsinnehållet (före/efter-värden) finns bakom alertData.

Lista aviseringarKopiera länk till rubriken

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

Filter tillgängliga i where:

• states — UNRESOLVED och/eller RESOLVED
• kinds: de fem datasettyperna, PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION, CUSTOM_SCREENING_LISTS
• entity — alla aviseringar för ett Entitet-id
• entityKind — standardvärdet är COMPANY; ange det explicit om du övervakar privata Personer
• period — ett tidsfönster för när aviseringen skapades
• page — paginering med limit/offset

Hämta vad som ändradesKopiera länk till rubriken

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

Använd alertData vid behov (lazily) — hämta det när ditt system faktiskt bearbetar aviseringen, inte vid listning.

Hantera aviseringarKopiera länk till rubriken

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

• De enda statusarna är UNRESOLVED och RESOLVED — att hantera en avisering är reversibelt.
• Hantering via API:et registreras i samma granskningskedja som hantering i appen (resolvedBy, resolvedAt), och aviseringar du hanterar via API:et försvinner även från ditt Teams kö i appen. En hanteringsmodell, två gränssnitt.
• Det finns inget fält för Ansvarig eller kommentar på Connect-aviseringsytan — tilldelning sker på Entitet-nivå och hanteras i appen.

IntegrationsmönsterKopiera länk till rubriken

Den rekommenderade loopen för att synkronisera aviseringar till ert eget system:

1. Polla alerts(where: { states: [UNRESOLVED] }) enligt ett schema som matchar screening-kadensen – Företag screenas fem nätter per vecka, privata Personer dagligen, så att polla oftare än en gång i timmen ger ingenting. Se screening-kadens.
2. Deduplicera på aviseringens id; använd insertedAt för inkrementell hämtning.
3. Hämta detaljer via alertData för de aviseringar som er process faktiskt hanterar.
4. Hantera via alertUpdate när de har hanterats på er sida, så att båda systemen är överens om vad som är utestående.

WebhooksKopiera länk till rubriken

För att få nya aviseringar utan att polla, prenumerera på webhooken monitoring.alert.created. Strise skickar den en gång för varje ny avisering, så snart aviseringen finns tillgänglig i alerts. Nyttolasten innehåller aviseringens alertId, entityId, entityKind, kind, computedAt och insertedAt. alerts returnerar samma fält för en ny avisering. Gå direkt till steg 3 och anropa 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"
  }
}

Kuvertet runt data är detsamma för varje händelse; se Vad du tar emot.

Använd webhooken som trigger och alerts som sanningskälla:

• Webhooken rapporterar endast att en avisering skapades. Den rapporterar inte att någon hanterade aviseringen i appen eller via API:et. För att hämta aktuell state, filtrera alerts på entity, entityKind och kinds. entityKind har standardvärdet COMPANY, så ange det för aviseringar gällande privata Personer.
• Behåll en periodisk pollning av alerts som reserv, så att du fortfarande fångar upp en avisering vars leverans din slutpunkt aldrig bekräftade. Deduplicera på aviseringens id: alertId i webhook-nyttolasten, id i alerts.

Relaterade sidorKopiera länk till rubriken

• Synkronisera din kundlista — få in Entiteter i Övervakning via API:et
• Inställningar för övervakningsaviseringar — vilka aviseringskategorier ditt Team har aktiverat (API:et returnerar endast aviseringar för aktiverade kategorier)
• Vanliga frågor om API