Webhooks

Webhooks provide real-time, event-driven communication between RiskOS™ and your applications. When specific events occur in RiskOS™ (such as decision changes in Case Management), HTTP POST requests are automatically sent to your configured endpoints with relevant event data.


Webhook testing tools

To quickly verify that events are being successfully triggered and sent by RiskOS™, you can use Webhook Cool (or a similar tool), which will provide you with a unique URL to receive the events.

⚠️

Security note:

When using external testing tools like Webhook Cool, please be mindful that your webhook payload will contain your authorization as well as sensitive customer information (depending on your workflow configuration). RiskOS™ does not endorse this third-party tool and is not responsible for the security or handling of data received by Webhook Cool or any other external service. Use such tools only for non-production testing and with awareness of the data being exposed.


Quick start

  1. Prepare your endpoint

    Create an HTTPS endpoint capable of receiving POST requests from RiskOS™. Ensure the endpoint accepts application/json payloads, validates authentication, and returns a 2xx response code after successful receipt.

  2. Access the Developer Workbench

    Go to Developer Workbench > Webhooks in the RiskOS™ Dashboard. From this page, you can view, edit, or create webhook configurations for your account.


  3. Create a new webhook

    Click + New Webhook and enter the following details:

    • Name: A descriptive name to help identify this webhook later.
    • URL: The HTTPS destination endpoint that will receive webhook events.
    • Use Case: Scope webhook delivery to a specific RiskOS™ use case (for example, Consumer Onboarding or Account Takeover).
    • Event Type: Select one or more event types to subscribe to. Each event follows a predefined schema.
    • Auth Type: Choose from the supported authentication methods:
      • Basic Authentication — Username and password-based authentication.
      • Bearer Token — Uses a UUID token for authentication.
      • OAuth2 — Requires a client ID, client secret, and token URL.

  4. Test your webhook

    Click Continue to Test to send a sample payload to your endpoint. The RiskOS™ Dashboard will display success or failure results, confirming whether your webhook is reachable and properly configured.

  5. Activate your webhook

    Once the test is successful, click Save to activate your webhook for real-time event delivery. RiskOS™ will now begin sending event notifications whenever subscribed events occur.


Manage webhooks

Users with the appropriate permissions can configure and manage their webhooks on the Developer Workbench > Webhooks section of the RiskOS™ Dashboard.

The Webhooks section displays all configured webhooks along with key details:

  • Webhook URL: Destination endpoint that receives event payloads.
  • Created / Last Modified: When the webhook was created or last updated.
  • Subscribed Events: Event types that trigger the webhook.

Delete a webhook

Click the trash icon for the webhook, then confirm Delete.


Advanced webhook settings

Header variables

RiskOS™ supports static header variables. For setup, contact your Solutions Consultant.


Retry mechanism

If delivery fails due to specific HTTP responses, RiskOS™ retries up to 10 times with exponential backoff:

  • Backoff grows up to 60 seconds.
  • From the 6th attempt onward, retries occur at 1-minute intervals (for the remaining 4 attempts).
  • Retries occur on: 504, 503, 502, 429, 423, 409, 408.
  • Design for idempotency using event_id to avoid duplicate processing.

IP allowlisting

Allow outbound calls from RiskOS™ to your endpoint:

  • Sandbox: 35.230.191.253/32
  • Production: 35.199.32.202/32, 3.138.161.243
👍

Tip:

If you use a WAF or API gateway, add these to source IP allowlists and confirm with an end-to-end test.


Security recommendations

  • Use HTTPS and one of the supported auth methods (Basic, Bearer, OAuth2).
  • Validate inputs: treat payloads as untrusted; enforce JSON schema and size limits.
  • Store minimal data from the webhook; fetch additional details from your backend if needed.
  • Log event_id, event_type, and event_at for observability and replay support.

Sample receivers

Use the code samples below as a starting point. They acknowledge quickly and de-duplicate via event_id.

import express from "express";
import crypto from "crypto";

const app = express();
app.use(express.json({ type: "application/json" }));

// Replace with a real, persistent store:
const seen = new Set();

app.post("/webhooks/riskos", async (req, res) => {
  const { event_id, event_type, data } = req.body || {};
  if (!event_id || !event_type) return res.status(400).send("Bad Request");

  // Idempotency: drop duplicates
  if (seen.has(event_id)) return res.status(200).send("OK");
  seen.add(event_id);

  // Queue async work (do not block the response)
  queueMicrotask(() => handleEvent(event_type, data).catch(console.error));

  return res.status(200).send("OK");
});

async function handleEvent(type, data) {
  switch (type) {
    case "evaluation_completed":
      // process...
      break;
    default:
      // no-op
  }
}

app.listen(3000, () => console.log("Listening on :3000"));
from flask import Flask, request, jsonify

app = Flask(__name__)
seen = set()  # replace with durable store

@app.post("/webhooks/riskos")
def riskos():
    payload = request.get_json(silent=True) or {}
    event_id = payload.get("event_id")
    event_type = payload.get("event_type")
    data = payload.get("data")

    if not event_id or not event_type:
        return ("Bad Request", 400)

    if event_id in seen:
        return ("OK", 200)
    seen.add(event_id)

    # Do processing async/off-thread in production
    handle_event(event_type, data)
    return ("OK", 200)

def handle_event(event_type, data):
    if event_type == "evaluation_paused":
        pass  # handle
    # etc.

if __name__ == "__main__":
    app.run(port=3000)

Troubleshooting

IssueExplanationSuggested fix
Tester shows failureEndpoint may be blocked by a firewall or web application firewall (WAF).Allowlist RiskOS™ IPs (Sandbox/Prod) and retest.
Duplicate processingRetries or replayed events can cause duplicate handling.Use event_id for idempotency. Acknowledge quickly and process asynchronously.
TimeoutsThe endpoint is performing long or blocking operations inline.Return a 2xx response immediately and move heavy processing to background jobs.
401 / 403 errorsAuthentication credentials or tokens are invalid or misconfigured.Verify Basic credentials, Bearer token, or OAuth2 client details and token URL.
429 / 5xx errorsRate limiting, transient network failures, or downstream service errors.Ensure the endpoint is retry-safe and idempotent. Add horizontal scaling or caching to handle spikes.
Sudden drop in auto-acceptance ratesMay be caused by repeat failed users, demographic shifts, or risk model changes.Investigate repeat PII patterns. Monitor demographic distribution. Review triggered risk signals (e.g., I912, R940) and recent model or logic updates.