Event types

An event type is defined according to a business context of your operation. Examples: financial transaction (transaction), user authentication (user_authentication), or logistics delivery milestones (logistics_delivery_event).

The event type defines the data contract of an event: how the event must be structured, which data is relevant for analysis, and how that data can be monitored over time.

Difference between event type and event

event type: the data model and validation rules.
event: the actual occurrence sent to the API, following the event type model.

Every event always belongs to a previously configured event type.

In the POST /events API, the event’s type attribute states the ID of the registered event type. If the specified type does not exist or is inactive, the platform rejects the submission.

Contract per business context

With event types, the integration no longer depends on a rigid contract per business domain and follows a more flexible model:

the event type is defined according to the business context;
standardized events are sent to the POST /events endpoint;
the model evolves with less coupling between product and integration.

Main components

An event type typically includes:

fields: the event structure (for example: identifiers, values, status, and context attributes);
metrics: aggregations and indicators derived from received events;
monitors: criteria and views for operational tracking, risk, and performance;
analyses: risk scorers that score the recent behavior of each event;
rules: logic evaluated over each event received, at the moment it arrives.

This combination models different business flows without a specific endpoint for each new use case.

Fields

Fields define the data contract of the event type. See Fields for details on configuration, data types, and validation rules.

Analyses

Analyses accumulate the recent history of events in sliding windows and return a risk score for each new event, queried by rules. See Analyses for the configuration of cells, measures, and signals.

Last event received

The event type records the moment it received its last event, shown in the panel. It is the most direct reading to confirm that an integration is sending data and to spot an event type that stopped receiving.

Default rule

An event type can specify a default rule, applied to every event of that type when the request does not explicitly state which rule to run. This is the recommended way to operate when a single piece of logic covers the event type: the integration only sends data, and the rule becomes panel configuration.

Providing rule.name in the request overrides the default rule.

Relationship with the /events API

Once an event type is defined, each occurrence is sent to POST /events following the corresponding contract.

This pattern favors:

standardization of data ingestion;
continuous evolution of the model;
reuse of metrics and monitors across scenarios.

Failure event type

Every account has a reserved event type, _failure, that records what went wrong in the account’s integration. Failures include requests rejected by the events API, rules that failed while processing an event, and monitors that did not run. The account follows failures as it follows any other events, instead of noticing failures only through missing data.

Query failures in Explore or through the agent, like the events of any type. In the event type list, _failure carries the System mark. In Explore’s event type menu, _failure is under More.

The platform manages the _failure event type:

its fields cannot be edited;
no rule can be attached to the event type;
the API does not accept events posted to _failure;
the event type does not count toward the account’s event type limit;
its events are kept for 7 days.

Event type IDs starting with _ are reserved for system types.

Alert event type

Every account has a reserved event type, _alert, with an event for each opening and each closing of a monitor alert. The alert history can be queried in Explore, measured by metrics and followed by monitors, like any other events.

_alert events are kept for the same period as other events, as described in Original data. An alert stops being shown with the metric’s retention, but its opening and closing events remain. Alerts from before the event type was created are not part of the history.

Field	Panel label	Content
`event`	Event	Opened, Normalized, Expired or Disabled, according to the lifecycle
`monitor`	Monitor	monitor that opened the alert
`metric`	Metric	the monitor’s metric
`aggregation`	Aggregation	monitored aggregation
`event_type`	Event type	the metric’s event type
`interval`	Interval	the monitor’s interval, from 1 minute to 7 days
`direction`	Direction	Rise or Drop; absent on an alert opened by conditions alone
`segment`	Segment	the alert’s segment; absent on a monitor without segmentation
`segment_hash`	Segment hash	segment identifier, to group the alerts of the same segment
`value`	Value	observed value; only on opening
`threshold`	Crossed threshold	crossed threshold; only on opening
`duration_seconds`	Duration (seconds)	duration of the alert; only on closing

The opening and the closing of the same alert share the same event ID. The monitor, metric, aggregation and event type fields show the resource’s current name, including for a removed resource. Alert ratings are not part of the event type.

The platform manages the _alert event type like the failure one, with the System mark and under More in Explore:

its fields cannot be edited;
no rule can be attached to the event type;
the API does not accept events posted to _alert;
the event type does not count toward the account’s event type limit;
a monitor on _alert itself does not generate alert events.

Best practices

Use clear and stable names for event types.
Avoid overly generic types with no business semantics.
Handle contract changes with planned versioning.
Document the required status and format of each field for the integration team.

Event type examples