WebhooksKopiér link til overskriften

Strise kan sende hændelser til et HTTPS-endpoint, du kontrollerer. Når der sker noget væsentligt i din portefølje, såsom en færdig vurdering, en statusændring på en kundeorienteret formular eller en ny overvågningsalert, sender Strise en signeret HTTP-anmodning til din server i nær realtid. Dine systemer kan derefter reagere uden polling.

Hvor det konfigureresKopiér link til overskriften

Administrer abonnementer under Settings → Team → Webhooks. Kun team managers kan oprette eller redigere dem. Hvert abonnement har en endpoint-URL, det sæt af hændelsestyper, du ønsker, og en aktiv-til/fra-knap.

Understøttede hændelserKopiér link til overskriften

Flere hændelser vil blive tilføjet over tid. Kontakt Strise, hvis der er en, du gerne vil se.

newStatus på form.status.changed kan også være INCONCLUSIVE – formularen blev udfyldt, men dokumentverifikationstrinnet kunne ikke afklares endeligt.

I monitoring.alert.created er entityKind Company eller PrivatePerson. kind er PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION eller CUSTOM_SCREENING_LISTS, værdierne i Connect-enummet DatasetKind. Hent hvad der ændrede sig med alertData(alert: "<alertId>").

Strise sender kun monitoring.alert.created for alerts, som Connect-forespørgslen alerts returnerer til dit team, så du kan slå ethvert alertId op. Teams, der ikke har funktionen Overvågningsvisning, modtager ingen hændelser. Alerter om ændringer i en persons oplysninger og alerter om ændringer i risikoniveau sender ingen hændelse, fordi Connect API endnu ikke returnerer dem. Hvis du skjuler visningen for overvågningsalerts under Indstillinger for overvågningsalerts, stopper det ikke hændelserne.

Send en testhændelseKopiér link til overskriften

Når et abonnement er aktivt, kan du udløse en rigtig levering efter behov for at tjekke dit endpoint – ingen grund til at vente på, at en live vurdering bliver færdig, eller at en formular skifter status. Under Settings → Team → Webhooks bruger du abonnementets handling Send mock event, vælger en af de hændelsestyper, det abonnerer på, gennemgår JSON-payloaden og sender.

Strise udgiver testhændelsen gennem den samme pipeline som en produktionslevering: den samme signerede kuvert og OIDC-token, sendt til det endpoint, du har registreret. En testhændelse afprøver derfor din signaturverificering og din modtagerlogik ende-til-ende mod en payload, du kan se på forhånd. Afsendelse er begrænset til team managers og kun, mens abonnementet er aktivt.

Samme hændelses-id ved hver genafsendelseKopiér link til overskriften

Genafsendelse af den samme mock-hændelse frembringer en levering med det samme id hver gang. Dette er tilsigtet: det giver dig mulighed for at bekræfte, at din deduplikering virker. En modtager, der deduplikerer på hændelsens id, behandler den første levering og ignorerer identiske genafsendelser – så hvis en gentagen testhændelse holder op med at dukke op downstream, gør din deduplikering sit arbejde.

Hvad du modtagerKopiér link til overskriften

Et HTTPS POST til det endpoint, du har registreret, med:

• Header Authorization: Bearer <JWT> – det token, du verificerer (nedenfor).
• Hændelsen som den rå JSON-body. Kuverten indeholder alt, hvad du behøver for at identificere, dirigere og deduplikere en levering – ingen andre headere er nødvendige til behandlingen.

{
  "id": "4bdf74b2-0d8e-3379-9739-cba7db9b602d",
  "version": "1",
  "eventType": "form.status.changed",
  "teamId": "b07e18b1-45bf-4d5d-877e-ad0374d70111",
  "subscriptionId": "76a48168-145b-495a-8cec-0ee929d8c15c",
  "timestamp": "2026-05-27T12:41:58.985818515",
  "data": {
    "formInstanceId": "…",
    "entityId": "…",
    "entityKind": "Company",
    "oldStatus": "IN_PROGRESS",
    "newStatus": "SUCCESS"
  }
}

Dit endpoint skal være HTTPS – Strise pusher ikke til almindelig HTTP, og payloadens integritet under overførsel afhænger af TLS. Se Kvittering for leveringen nedenfor for at se, hvordan du svarer.

Endpointet skal desuden bruge et offentligt domænenavn, der udelukkende resolver til offentlige IP-adresser. Strise afviser IP-adresser, loginoplysninger i URL'en (user:pass@) og interne navne såsom localhost eller *.internal, når du opretter abonnementet eller sender en testhændelse.

Verificering af signaturenKopiér link til overskriften

Enhver levering indeholder en Authorization: Bearer <JWT>-header med et Google-udstedt OIDC-token, signeret på vegne af Strises tjenestekonto til levering. Verificering af det beviser, at anmodningen kom fra Strise og nåede frem til dig uændret. Verificer det, før du stoler på payloaden.

Hvad der skal verificeres modKopiér link til overskriften

email er en fast Strise-værdi (ovenfor). aud er den endpoint-URL, du indtastede, da du oprettede abonnementet – Strise sætter tokents audience til dit push-endpoint.

⚠️ Reglen, der betyder mestKopiér link til overskriften

En gyldig Google-signatur alene beviser ikke, at anmodningen er fra Strise. Enhver med en Google Cloud-konto kan hente et Google-signeret OIDC-token (iss: https://accounts.google.com, gyldig signatur). Det, der knytter et token til Strise, er email-claimet (tjenestekontoen til levering) sammen med aud-claimet (dit endpoint).

Tjek altid både email og aud efter verificering af signaturen. Hvis du kun verificerer signaturen eller kun udstederen, er du sårbar over for spoofing.

VerificeringstrinKopiér link til overskriften

1. Udtræk tokenet fra Authorization: Bearer-headeren.
2. Hent Googles offentlige nøgler (bibliotekerne nedenfor cacher og roterer dem automatisk for dig).
3. Verificer signaturen og standard-claims (iss, exp).
4. Bekræft, at aud matcher din registrerede endpoint-URL.
5. Bekræft, at email er lig med webhook-delivery@strise-prod.iam.gserviceaccount.com (og at email_verified er true).
6. Først derefter kan du stole på og behandle hændelsens JSON i anmodningens body.

KodeeksemplerKopiér link til overskriften

Hvert eksempel verificerer headeren og returnerer claims ved succes. Erstat EXPECTED_AUDIENCE med den endpoint-URL, du registrerede.

Node.js — google-auth-libraryKopiér link til overskriften

import { OAuth2Client } from 'google-auth-library'

const client = new OAuth2Client()
const EXPECTED_EMAIL = 'webhook-delivery@strise-prod.iam.gserviceaccount.com'
const EXPECTED_AUDIENCE = 'https://your-domain.example.com/strise-webhook'

// Throws if the token is missing, invalid, expired, or not issued by Strise.
export async function verifyStriseWebhook(authorizationHeader) {
  if (!authorizationHeader?.startsWith('Bearer ')) throw new Error('missing bearer token')
  const token = authorizationHeader.slice('Bearer '.length)

  // Verifies the Google signature (JWKS), iss, exp, and aud.
  const ticket = await client.verifyIdToken({ idToken: token, audience: EXPECTED_AUDIENCE })
  const claims = ticket.getPayload()
  if (claims.email !== EXPECTED_EMAIL || claims.email_verified !== true) {
    throw new Error('token not issued by Strise')
  }
  return claims
}

Python — google-authKopiér link til overskriften

from google.oauth2 import id_token
from google.auth.transport import requests as google_requests

EXPECTED_EMAIL = "webhook-delivery@strise-prod.iam.gserviceaccount.com"
EXPECTED_AUDIENCE = "https://your-domain.example.com/strise-webhook"

def verify_strise_webhook(authorization_header: str) -> dict:
    if not authorization_header.startswith("Bearer "):
        raise ValueError("missing bearer token")
    token = authorization_header[len("Bearer "):]

    # Verifies the Google signature (JWKS), iss, exp, and aud.
    claims = id_token.verify_oauth2_token(token, google_requests.Request(), audience=EXPECTED_AUDIENCE)
    if claims.get("email") != EXPECTED_EMAIL or not claims.get("email_verified"):
        raise ValueError("token not issued by Strise")
    return claims

Go — google.golang.org/api/idtokenKopiér link til overskriften

import (
	"context"
	"fmt"
	"strings"

	"google.golang.org/api/idtoken"
)

const (
	expectedEmail    = "webhook-delivery@strise-prod.iam.gserviceaccount.com"
	expectedAudience = "https://your-domain.example.com/strise-webhook"
)

// VerifyStriseWebhook returns the verified claims, or an error if the token is
// missing, invalid, expired, or not issued by Strise.
func VerifyStriseWebhook(ctx context.Context, authorizationHeader string) (*idtoken.Payload, error) {
	token := strings.TrimPrefix(authorizationHeader, "Bearer ")
	if token == authorizationHeader {
		return nil, fmt.Errorf("missing bearer token")
	}

	// Validate verifies the Google signature (JWKS), iss, exp, and aud.
	payload, err := idtoken.Validate(ctx, token, expectedAudience)
	if err != nil {
		return nil, err
	}
	if payload.Claims["email"] != expectedEmail || payload.Claims["email_verified"] != true {
		return nil, fmt.Errorf("token not issued by Strise")
	}
	return payload, nil
}

Kvittering for leveringenKopiér link til overskriften

Svar med en vilkårlig 2xx-statuskode for at kvittere for modtagelsen. Et ikke-2xx-svar (eller et timeout) får Strise til at forsøge at sende den samme payload igen.

Kvitter altid, selv hvis din egen behandling mislykkes. Hvis din downstream-modtager fejler – en databaseskrivning kaster en fejl, din kø er fuld, en undtagelse bobler op – skal du stadig svare 2xx og håndtere fejlen på din side (log, advisér, prøv igen fra din egen kø). Et ikke-2xx-svar fortæller Strise, at beskeden ikke nåede frem til dig, så vi bliver ved med at forsøge at sende den identiske payload igen. Det løser sjældent en downstream-fejl og forstærker blot støjen i dit system.

Almindelige fejlscenarierKopiér link til overskriften

• Verificering af signaturen, men ikke email/aud – signaturen beviser kun, at Google udstedte tokenet, ikke at Strise gjorde det. Tjek altid begge claims. Dette er den mest almindelige fejl.
• Afkodning uden verificering – base64-afkodning af JWT-bodyen for at læse claims uden at validere signaturen fæstner lid til angriber-leverede data. Brug et bibliotek, der verificerer.
• Forkert aud – audience skal svare nøjagtigt til den endpoint-URL, du registrerede (den URL, Strise pusher til), ikke et tjenestenavn eller en anden sti.
• Ur-forsinkelse (clock skew) – exp ligger cirka en time fremme i tiden. Hvis din servers ur driver, bliver gyldige tokens afvist. Hold det NTP-synkroniseret; bibliotekerne ovenfor tolererer et par sekunders afvigelse.
• Fjernet Authorization-header – visse load balancere og API gateways fjerner eller omskriver Authorization. Sørg for, at den når frem til din applikation intakt.
• Nøglerotation – Google roterer sine signeringsnøgler periodisk. Alle tre biblioteker henter og cacher JWKS og følger rotationen automatisk; foretag aldrig pinning af en nøgle.
• Genafspilninger (replays) – et opsnappet token er gyldigt indtil exp (~1 time). Deduplikér på hændelsens id i payloaden (stabil på tværs af genleveringer), så genbehandling er ufarlig.