WebhooksKopier lenke til overskriften

Strise kan sende hendelser til et HTTPS-endepunkt du kontrollerer. Når noe viktig skjer i din portefølje, som en fullført vurdering, en statusendring på et kunderettet skjema eller et nytt monitoreringsvarsel, sender Strise en signert HTTP-forespørsel til serveren din i nesten sanntid. Systemene dine kan deretter reagere uten polling.

Hvor du konfigurererKopier lenke til overskriften

Administrer abonnementer under Settings → Team → Webhooks. Kun team-administratorer kan opprette eller redigere dem. Hvert abonnement har en endepunkt-URL, settet med hendelsestyper du ønsker, og en aktiveringsbryter.

Støttede hendelserKopier lenke til overskriften

Flere hendelser vil bli lagt til over tid. Kontakt Strise dersom det er en spesiell du ønsker å se.

newStatus på form.status.changed kan også være INCONCLUSIVE – skjemaet ble fullført, men dokumentverifiseringstrinnet kunne ikke avklares entydig.

I monitoring.alert.created er entityKind enten Company eller PrivatePerson. kind er PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION eller CUSTOM_SCREENING_LISTS, som er verdiene i Connect DatasetKind-enumen. Hent hva som ble endret med alertData(alert: "<alertId>").

Strise sender monitoring.alert.created kun for varsler som Connect alerts-spørringen returnerer til ditt team, slik at du kan slå opp hver alertId. Team som ikke har funksjonen for monitoreringsvisning, mottar ingen hendelser. Varsler om endringer i en persons opplysninger og varsler om endringer i risikonivå sender ingen hendelse, fordi Connect API-et ikke returnerer dem ennå. Å skjule visningen for monitoreringsvarsler under Monitoring Alerts Settings stopper ikke hendelsene.

Send en testhendelseKopier lenke til overskriften

Når et abonnement er aktivt, kan du utløse en reell levering ved behov for å kontrollere endepunktet ditt – du trenger ikke vente på at en faktisk vurdering fullføres eller at et skjema endrer status. Under Settings → Team → Webhooks bruker du abonnementets Send mock event-handling, velger en av hendelsestypene det abonnerer på, går gjennom JSON-payloaden og sender.

Strise publiserer testhendelsen gjennom samme pipeline som en produksjonslevering: den samme signerte konvolutten og OIDC-tokenet, sendt til endepunktet du registrerte. En testhendelse tester derfor din signaturverifisering og din handler ende-til-ende, mot en payload du kan se på forhånd. Sending er begrenset til team-administratorer, og kun mens abonnementet er aktivt.

Samme hendelses-id ved hver omsendingKopier lenke til overskriften

Å sende den samme mock-hendelsen på nytt gir en levering med samme id hver gang. Dette er tilsiktet: det lar deg bekrefte at dedupliseringen din fungerer. En mottaker som dedupliserer på hendelsens id, behandler den første leveringen og ignorerer identiske omsendinger – så hvis en gjentatt testhendelse slutter å dukke opp nedstrøms, gjør dedupliseringen jobben sin.

Hva du mottarKopier lenke til overskriften

En HTTPS POST til endepunktet du registrerte, med:

• Header Authorization: Bearer <JWT> – tokenet du verifiserer (nedenfor).
• Hendelsen som rå JSON-body. Konvolutten inneholder alt du trenger for å identifisere, rute og deduplisere en levering – ingen andre headere er nødvendige for behandling.

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

Endepunktet ditt må være HTTPS – Strise vil ikke sende til vanlig HTTP, og payloadens integritet under overføring avhenger av TLS. Se Bekrefte leveringen nedenfor for hvordan du skal svare.

Endepunktet må også bruke et offentlig domenenavn som kun løses opp til offentlige IP-adresser. Strise avviser IP-adresser, påloggingsinformasjon i URL-en (user:pass@) og interne navn som localhost eller *.internal når du oppretter abonnementet eller sender en testhendelse.

Verifisere signaturenKopier lenke til overskriften

Hver levering inneholder en Authorization: Bearer <JWT>-header med et Google-utstedt OIDC-token, signert på vegne av Strises tjenestekonto for levering. Verifisering beviser at forespørselen kom fra Strise og nådde deg uendret. Verifiser det før du stoler på payloaden.

Hva du skal verifisere motKopier lenke til overskriften

email er en fast Strise-verdi (ovenfor). aud er endepunkt-URL-en du oppga da du opprettet abonnementet – Strise setter tokenets audience til ditt push-endepunkt.

⚠️ Regelen som betyr mestKopier lenke til overskriften

En gyldig Google-signatur alene beviser ikke at forespørselen er fra Strise. Hvem som helst med en Google Cloud-konto kan skaffe et Google-signert OIDC-token (iss: https://accounts.google.com, gyldig signatur). Det som knytter et token til Strise, er email-claimet (tjenestekontoen for levering) sammen med aud-claimet (ditt endepunkt).

Sjekk alltid både email og aud etter at du har verifisert signaturen. Å verifisere kun signaturen eller kun utstederen gjør deg sårbar for spoofing.

VerifiseringstrinnKopier lenke til overskriften

1. Hent ut tokenet fra Authorization: Bearer-headeren.
2. Hent Googles offentlige nøkler (bibliotekene nedenfor cacher og roterer dem for deg).
3. Verifiser signaturen og standard claims (iss, exp).
4. Bekreft at aud er lik din registrerte endepunkt-URL.
5. Bekreft at email er lik webhook-delivery@strise-prod.iam.gserviceaccount.com (og at email_verified er true).
6. Først da kan du stole på og behandle hendelsens JSON i forespørselskroppen.

KodeeksemplerKopier lenke til overskriften

Hvert eksempel verifiserer headeren og returnerer claims ved suksess. Erstatt EXPECTED_AUDIENCE med endepunkt-URL-en du registrerte.

Node.js — google-auth-libraryKopier lenke 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-authKopier lenke 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/idtokenKopier lenke 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
}

Bekrefte leveringenKopier lenke til overskriften

Svar med en 2xx-statuskode for å bekrefte mottak. En respons som ikke er 2xx (eller en tidsavbrudd) gjør at Strise prøver å sende den samme payloaden på nytt.

Bekreft alltid mottak, selv om din egen behandling feiler. Hvis din nedstrøms-handler feiler – en databaseskriving kaster en feil, køen din er full, et unntak bobler opp – svar likevel med 2xx og håndter feilen på din side (loggfør, varsle, prøv igjen fra din egen kø). En ikke-2xx-respons forteller Strise at meldingen ikke nådde frem til deg, så vi fortsetter å prøve den identiske payloaden på nytt. Det løser sjelden en nedstrømsfeil og forsterker bare støyen på din side.

Vanlige feilsituasjonerKopier lenke til overskriften

• Verifisere signaturen, men ikke email/aud – signaturen beviser kun at Google utstedte tokenet, ikke at Strise gjorde det. Sjekk alltid begge claims. Dette er den vanligste feilen.
• Dekoding uten verifisering – base64-dekoding av JWT-bodyen for å lese claims, uten å validere signaturen, stoler på data levert av en angriper. Bruk et bibliotek som verifiserer.
• Feil aud – audience må være nøyaktig lik endepunkt-URL-en du registrerte (URL-en Strise pusher til), ikke et tjenestenavn eller en annen sti.
• Klokkeavvik (clock skew) – exp er omtrent én time frem i tid. Hvis serverklokken din avviker, blir gyldige tokens avvist. Hold den NTP-synkronisert; bibliotekene ovenfor tolererer noen sekunders avvik.
• Fjernet Authorization-header – enkelte lastbalanserer og API-gatewayer fjerner eller omskriver Authorization. Sørg for at den når applikasjonen din intakt.
• Nøkkelrotasjon – Google roterer signeringsnøklene sine periodisk. Alle tre bibliotekene henter og cacher JWKS og følger rotasjonen automatisk; lås aldri en nøkkel.
• Gjentakelser (replays) – et oppfanget token er gyldig frem til exp (~1 time). Dedupliser på hendelsens id i payloaden (stabil på tvers av nye leveringsforsøk), slik at reprosessering er ufarlig.