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.

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.

Table of contents