Övervakningsaviseringar via API

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

Modellen

Tre operationer täcker hela flödet:

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

Lista aviseringar

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

Filter tillgängliga i where:

• states — UNRESOLVED och/eller RESOLVED
• kinds — de fyra dataset-typerna: PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION
• entity — alla aviseringar för ett entitets-id
• entityKind — standardvärde är COMPANY; ange explicit om du övervakar privatpersoner
• period — ett tidsfönster för när aviseringen skapades
• page — paginering med limit/offset

Hämta vad som ändrades

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 behandlar aviseringen, inte vid listningen.

Åtgärda aviseringar

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

• De enda tillstånden är UNRESOLVED och RESOLVED — att åtgärda är reversibelt.
• Åtgärdande via API:et registreras i samma granskningskedja som åtgärdande i appen (resolvedBy, resolvedAt), och aviseringar du åtgärdar via API:et försvinner även från ditt teams kö i appen. En åtgärdsmodell, två gränssnitt.
• Det finns inget fält för ansvarig eller kommentarer på aviseringsytan i Connect — tilldelning av ansvarig sker på entitetsnivå och hanteras i appen.

Integrationsmönster

Det rekommenderade flödet för att synka aviseringar till ditt eget system:

1. Polla alerts(where: { states: [UNRESOLVED] }) enligt ett schema som matchar screening-kadensen — företag screenas fem nätter i veckan, privatpersoner 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. Åtgärda via alertUpdate när den har hanterats på er sida, så att båda systemen är överens om vad som är utestående.

Om du föredrar push framför polling, se Webhooks för händelseleverans och kombinera: webhook som trigger, alerts som sanningskälla.

Relaterade sidor

• Synka 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)
• API FAQ