Skip to main content
Which of these two applies to your account depends on your Risk Monitoring version. Accounts on Risk Monitoring v2 use risk.policy_alert, which reports a policy you defined and tells you which condition made it fire. Accounts on the earlier version use risk.alert, which reports the score based alerts configured from your score ranges. Your account is offered the event that matches its version, so in practice you subscribe to one of the two, not both. risk.alert is being phased out as accounts move to Risk Monitoring v2. If you are unsure which applies to you, the event list on your webhook endpoint shows the one your account uses.

risk.policy_alert

One event is delivered per alert. A monitoring run that trips three policies delivers three events, each carrying only its own policy’s conditions.

Fields

risk_alert_subtype and risk_level carry your own labels, not values from a fixed list. Both are editable in the dashboard, so renaming a category or a risk bucket changes what arrives in these fields. Do not branch your integration on their exact string values. Use risk_alert_id to identify a policy, and triggered_conditions[].field to identify what was measured — both are stable.
run_id tells you which monitoring run the alert surfaced on. It does not always identify what caused it: data written by a business update can land inside a run’s comparison window and be reported by that run.

Condition entries

Each entry in triggered_conditions describes one condition that evaluated true.

risk.alert

The Worth Score based alert. Fires on a score refresh, an application edit, or a manual refresh.
On this event risk_level and risk_alert_subtype are fixed sets of values, unlike risk.policy_alert.