WebhooksKopiera länk till rubriken

Strise kan skicka händelser till en HTTPS-slutpunkt som du kontrollerar. När något betydande inträffar i din Portfölj, såsom en slutförd Granska, en Status-ändring på ett kundinriktat formulär eller en ny övervakningsalert, skickar Strise en signerad HTTP-förfrågan till din server i nästintill realtid. Dina system kan då reagera utan polling.

Var du konfigurerarKopiera länk till rubriken

Hantera prenumerationer under Settings → Team → Webhooks. Endast teamansvariga kan skapa eller redigera dem. Varje prenumeration har en slutpunkts-URL, den uppsättning händelsetyper du vill ha och ett aktivt reglage.

Händelser som stödsKopiera länk till rubriken

Fler händelser kommer att läggas till över tid. Kontakta Strise om det finns någon du skulle vilja se.

newStatus på form.status.changed kan också vara INCONCLUSIVE — formuläret slutfördes, men steget för dokumentverifiering kunde inte avgöras slutgiltigt.

I monitoring.alert.created är entityKind antingen Company eller PrivatePerson. kind är PEP, SANCTIONS, RELATIONS, COMPANY_INFORMATION eller CUSTOM_SCREENING_LISTS, värdena från Connect-enumen DatasetKind. Hämta det som ändrades med alertData(alert: "<alertId>").

Strise skickar monitoring.alert.created endast för alerts som Connect-frågan alerts returnerar till ditt Team, så att du kan slå upp varje alertId. Team som inte har funktionen för Övervakning-vyn tar inte emot några händelser. Alerts för ändringar i en Persons information och alerts för ändringar av risknivå skickar inga händelser, eftersom Connect API inte returnerar dem ännu. Att dölja vyn för övervakningsalerts under Inställningar för övervakningsalerts stoppar inte händelserna.

Skicka en testhändelseKopiera länk till rubriken

När en prenumeration är aktiv kan du utlösa en verklig leverans på begäran för att kontrollera din slutpunkt — du behöver inte vänta på att en skarp Granska ska slutföras eller att ett formulär ska ändra Status. Under Settings → Team → Webhooks använder du prenumerationens åtgärd Send mock event, väljer en av de händelsetyper den prenumererar på, granskar JSON-payloaden och skickar.

Strise publicerar testhändelsen via samma pipeline som en produktionsleverans: samma signerade kuvert och OIDC-token, skickat till slutpunkten du registrerade. En testhändelse testar därför din signaturverifiering och din hanterare från början till slut, mot en payload du kan se i förväg. Sändning är begränsad till teamansvariga, och endast medan prenumerationen är aktiv.

Samma händelse-id vid varje omsändningKopiera länk till rubriken

Att skicka samma mock-händelse igen ger en leverans med samma id varje gång. Detta är avsiktligt: det låter dig bekräfta att din deduplicering fungerar. En mottagare som deduplicerar på händelsens id bearbetar den första leveransen och ignorerar identiska omsändningar — så om en upprepad testhändelse slutar dyka upp längre ner i kedjan gör din deduplicering sitt jobb.

Vad du tar emotKopiera länk till rubriken

En HTTPS POST till slutpunkten du registrerade, med:

• Header Authorization: Bearer <JWT> — tokenen du verifierar (nedan).
• Händelsen som rå JSON-body. Kuvertet bär allt du behöver för att identifiera, dirigera och deduplicera en leverans — inga andra headers krävs för bearbetning.

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

Din slutpunkt måste vara HTTPS — Strise skickar inte till vanlig HTTP, och payloadens integritet under överföring bygger på TLS. Se Kvittera leveransen nedan för hur du ska svara.

Slutpunkten måste också använda ett publikt domännamn som endast löses upp till publika IP-adresser. Strise avvisar IP-adresser, autentiseringsuppgifter i URL:en (user:pass@) och interna namn som localhost eller *.internal när du skapar prenumerationen eller skickar en testhändelse.

Verifiera signaturenKopiera länk till rubriken

Varje leverans bär en Authorization: Bearer <JWT>-header som innehåller en Google-utfärdad OIDC-token, signerad för Strises tjänstekonto för leverans. Att verifiera den bevisar att förfrågan kom från Strise och nådde dig oförändrad. Verifiera den innan du litar på payloaden.

Vad du ska verifiera motKopiera länk till rubriken

email är ett fast Strise-värde (ovan). aud är den slutpunkts-URL du angav när du skapade prenumerationen — Strise sätter tokenens audience till din push-slutpunkt.

⚠️ Den viktigaste regelnKopiera länk till rubriken

En giltig Google-signatur i sig bevisar inte att förfrågan kommer från Strise. Vem som helst med ett Google Cloud-konto kan erhålla en Google-signerad OIDC-token (iss: https://accounts.google.com, giltig signatur). Det som knyter en token till Strise är claimet email (tjänstekontot för leverans) tillsammans med claimet aud (din slutpunkt).

Kontrollera alltid både email och aud efter att du har verifierat signaturen. Att endast verifiera signaturen eller endast utfärdaren gör dig sårbar för förfalskning (spoofing).

VerifieringsstegKopiera länk till rubriken

1. Extrahera tokenen från Authorization: Bearer-headern.
2. Hämta Googles publika nycklar (biblioteken nedan cachar och roterar dem åt dig).
3. Verifiera signaturen och standard-claims (iss, exp).
4. Kontrollera att aud är lika med din registrerade slutpunkts-URL.
5. Kontrollera att email är lika med webhook-delivery@strise-prod.iam.gserviceaccount.com (och att email_verified är true).
6. Först därefter kan du lita på och bearbeta händelsens JSON i förfrågans body.

KodexempelKopiera länk till rubriken

Varje exempel verifierar headern och returnerar claims vid framgång. Ersätt EXPECTED_AUDIENCE med den slutpunkts-URL du registrerade.

Node.js — google-auth-libraryKopiera länk till rubriken

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-authKopiera länk till rubriken

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/idtokenKopiera länk till rubriken

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
}

Kvittera leveransenKopiera länk till rubriken

Svara med valfri 2xx-statuskod för att kvittera mottagandet. Ett icke-2xx-svar (eller en timeout) gör att Strise försöker skicka samma payload igen.

Kvittera alltid, även om din egen bearbetning misslyckas. Om din hanterare längre ner i kedjan felar — en databasskrivning misslyckas, din kö är full, ett undantag uppstår — svara ändå 2xx och hantera felet på din sida (logga, larma, försök igen från din egen kö). Ett icke-2xx talar om för Strise att meddelandet inte nådde dig, så vi fortsätter att försöka skicka den identiska payloaden. Det löser sällan en bugg längre ner i kedjan och förstärker bara bruset på din sida.

Vanliga felorsakerKopiera länk till rubriken

• Verifierar signaturen men inte email/aud — signaturen bevisar bara att Google utfärdade tokenen, inte att Strise gjorde det. Kontrollera alltid båda claims. Detta är det vanligaste misstaget.
• Avkodning utan verifiering — att base64-avkoda JWT-bodyn för att läsa claims utan att validera signaturen innebär att du litar på data från en potentiell angripare. Använd ett bibliotek som verifierar.
• Felaktig aud — audience måste motsvara den exakta slutpunkts-URL du registrerade (den URL Strise skickar till), inte ett tjänstenamn eller en annan sökväg.
• Klockavvikelse — exp ligger ungefär en timme framåt i tiden. Om din servers klocka drar sig avvisas giltiga tokens. Se till att den är NTP-synkroniserad; biblioteken ovan tillåter några sekunders avvikelse.
• Borttagen Authorization-header — vissa lastbalanserare och API-gateways tar bort eller skriver om Authorization. Se till att den når din applikation intakt.
• Nyckelrotation — Google roterar sina signeringsnycklar periodiskt. Alla tre bibliotek hämtar och cachar JWKS och följer rotationen automatiskt; lås aldrig fast en nyckel (key pinning).
• Replays — en fångad token är giltig fram till exp (~1 timme). Deduplicera på händelsens id i payloaden (stabilt över återleveranser) så att upprepad bearbetning är ofarlig.