Event types

An event type is the structure that defines the data contract of an event in the platform.

In practice, it describes how an event should be structured, which data is relevant for analysis, and how that data can be monitored over time.

For example, you can configure event types for financial transactions (transaction), user authentication (user_authentication), or logistics delivery milestones (logistics_delivery_event).

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, this is handled through the event’s type attribute, which must specify the ID of the registered event type. If the specified type does not exist or is inactive, the submission is rejected.

What event types solve

With event types, the integration no longer depends on rigid endpoints per specific domain (such as payments) and instead follows a more flexible model:

  • you define the event type according to your business context;
  • you send standardized events to the POST /events endpoint;
  • you evolve the model 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: rules and views for operational tracking, risk, and performance.

This combination allows modeling different business flows without creating 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.

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