Risk push integration

Korala can notify your backend when risk evidence, assessments, tasks or overrides change. Your backend does not need to poll continuously to discover these changes. Use the notification as a reason to read current state, then apply your own account or payment authorization rules.

Connect an endpoint

In Settings → Webhooks, create an endpoint, select the Risk events you need, and choose Test or Live. Alternatively, call POST /api/v1/webhooks with url, events and mode. API-key subscriptions are pinned to the key’s environment. Keep the returned signing secret on your server; it is not an API key.

Only active, same-organization, same-environment subscriptions present when the change commits receive deliveries. Adding a subscription does not replay older history. Seed your initial view through the risk APIs, then use push notifications and occasional reconciliation to maintain it.

Payload and authentication

A notification contains resource references. It does not copy evidence values, customer names, policy rules or reviewer reasons into the payload.

{
  "eventId": "11111111-1111-4111-8111-111111111111",
  "event": "risk.assessment.created",
  "timestamp": "2026-09-28T10:00:00.000Z",
  "data": {
    "organizationId": "22222222-2222-4222-8222-222222222222",
    "subjectId": "33333333-3333-4333-8333-333333333333",
    "resourceId": "44444444-4444-4444-8444-444444444444",
    "sandbox": true
  }
}

eventId is the persisted risk event ID. It stays the same across retries and subscribers. resourceId identifies the changed subject, policy, event, evidence, assessment, action or override according to the event type. Policy notifications have subjectId: null.

Use the original request bytes with verifyWebhookSignature from @korala/auth:

const valid = verifyWebhookSignature(
  rawBody,
  request.headers['x-timestamp'],
  request.headers['x-signature'],
  webhookSecret,
);

Verify before parsing or processing. Check the signed body’s event, organization and data.sandbox against your configured connection. The timestamp verification rejects signatures outside the allowed time window. Do not authorize using the X-Webhook-Event header alone; compare it with the signed body.

In production, commit a deduplicated event to a durable inbox before returning a 2xx response, then reconcile asynchronously. Acknowledge duplicates successfully. Use (connection, eventId) as an inbox key and serialize updates for each subject or otherwise prevent an older reconciliation from overwriting a newer one.

Reconcile current risk

For risk.assessment.created, read GET /api/v1/risk/assessments/{resourceId}/state. For evidence, activity, action or override notifications, locate the subject’s latest assessment for each policy purpose and read its state. Follow every nextOffset when listing history.

A completed collection task does not clear a review decision. New evidence can make the earlier result stale before a replacement assessment exists. Respect current, effectiveDecision, evidence freshness, review deadlines and override expiry. none means no restriction under that policy, not blanket authorization.

Push events report committed changes. Monitored policies produce new assessments after evidence expiry or a review deadline, then emit assessment events. Unmonitored assessments and override expiry alone do not emit notifications. Clients must still enforce recorded deadlines.

Delivery behavior

Risk changes and their delivery records commit together. A worker dispatcher checks the durable delivery records on a five-second schedule, in batches of 100; queue load or worker downtime can delay delivery. A 60-second lease permits recovery after interrupted enqueueing. Delivery uses the existing webhook queue: five attempts, exponential backoff starting at 60 seconds, and a ten-second outbound request deadline. Korala reads at most 4 KiB of each response and stores a 1,000-character diagnostic preview. Failed deliveries remain visible and can be retried from Settings → Webhooks or the retry API.

Delivery is at-least-once, not exactly-once, and ordering is not guaranteed. Deduplicate even after a successful response: a process can stop after your handler commits but before Korala records delivery success. Test records are sent only to test subscriptions; mode is immutable on an existing subscription.

Test your webhook connection

Create a test-mode subscription, submit a fictional subject and evidence through the test API, and request an assessment. Confirm that your receiver verifies the signature, stores eventId for deduplication and fetches current state before acting. Then replace the evidence and verify that your receiver reconciles the new assessment and any open actions. Keep test and live subscriptions separate.

Paging delivery history

Treat nextCursor as opaque and pass it unchanged when requesting the next page for the same webhook and workspace mode. New cursors preserve deliveries with identical creation timestamps. Legacy timestamp cursors remain accepted during client upgrades. Invalid cursors and non-positive or non-integer limits return HTTP 400; page size is capped at 100.