Skip to content

Webhooks

Every decision as an event to an endpoint you run: the same id, the same reason codes and the same queue the app received, for your FRM, case manager or SIEM.

Webhooks and eventsEvents to your endpoint

On this page

How it works

Every decision DeepID makes is sent as an event to an endpoint you run, with the same id, reasons and queue the app received. Your FRM, case manager or SIEM picks it up from there.

Act on the event in your backend rather than on what the app reports. If your backend needs the decision before the event arrives, it can ask for it by id, server to server.

What it sends

  • decision.created: every decision, with its action, reason codes, customer message key, queue and policy version
  • Other event types: agreed in the sandbox

Set-up

  1. Agree the endpoint in the sandbox

    How events are delivered, signed and retried, and the headers your gateway will see, are agreed with your platform team before any contract.

  2. Receive decision.created

    Route it to the system that should act: the FRM for the case, the SIEM for device signals.

  3. Look a decision up by id when you need it first

    Your backend can fetch a decision server to server instead of waiting for the event.

Webhooks reference

More integrations.

How each decision reaches the systems your teams already use.

  • Your FRM system

    DeepID’s decisions reach your fraud risk management system as events, with the session signals it never sees today. Your FRM keeps its rules, queues and cases.

    FRM systemsDecision events into your FRM

  • Core banking and payment hubs

    Your backend checks the decision server to server before a payment reaches the core banking system or the rail, so a hold means the money never left.

    Core banking and paymentsServer-to-server decision check

See DeepID on a real phone.

We show your fraud, security and engineering leads how DeepID would run your sign-up, login or payment journey, then plan a pilot on your own traffic.