Skip to main content
POST
Normalize risk event

How Normalization Works

When you submit an identity event, the platform:
  1. Records the raw event in the audit trail
  2. Maps the event_type to a canonical signal type and base risk score
  3. Enriches the signal with available metadata (issuer trust tier, geo, device)
  4. Stores a risk_signal record ready for policy evaluation

Built-in Event Mappings

Unknown event types are accepted with a base score of 10 and signal type behavior.

Request

string
required
The system that generated this event: attestation, verification, login, consumer_portal
string
required
The raw event name (e.g. login.failed, verification.failed, attestation.deepfake_suspect)
string
required
Identifier of the entity involved in the event.
string
External reference ID (attestation_id, session_id, etc.) for cross-referencing.
string
Source IP address.
object
Raw event payload for enrichment context.

Response

string
UUID of the recorded raw event source.
string
UUID of the normalized risk signal created from this event.
string
The normalized signal type derived from the event.
integer
The base risk score assigned during normalization.
boolean
true if the event matched a known mapping; false if it used the generic fallback.

Authorizations

X-API-Key
string
header
required

API key for machine-to-machine authentication

Body

application/json
event_type
string
required
subject_id
string
required
data
object
timestamp
string

Response

Event ingested

event_id
string
signal_id
string