# Events

Send each real occurrence of the operation to `POST /events`: a payment attempt, an authentication, a registration update. The event type defines the contract; the event carries the data that occurred.

## Link to the event type

Every event states in the `type` attribute which event type it represents. The attribute is required.

The value of `type` must be the ID of an event type already configured and active in the account.

If the event type does not exist or is inactive, the API rejects the submission.

## Minimum submission structure

When submitting to `POST /events`, the main fields are:

* `type`: event type ID;
* `id`: unique identifier of the event;
* `attributes`: event data according to the fields configured in the type;
* `timestamp` (optional): date and time of the occurrence. Without this attribute, the platform uses the reception time;
* `rule.name` (optional): name of the [rule](/en/rules/) to run over this event. Without this attribute, the event type's default rule applies, if there is one.

Field names starting with `_` or `%` are reserved by the platform. The API rejects the submission if any of them appears in `attributes`.

## Inheritance between events under the same `id`

Several posts can share the same `id`, representing the same occurrence at different stages: the creation of an order and, minutes later, its outcome. A later post does not need to repeat everything already provided.

Each field of the event type defines whether it takes part in this inheritance, through the [Inheritance](/en/events/event_fields/#inheritance) setting. With inheritance enabled, a post that omits the field receives the value left by the previous post. With inheritance disabled, the field holds only for the post that carried it.

Inheritance carries the event as it was recorded, not only what the client sent. The fields filled in by a [rule](/en/rules/) during processing are also inherited. Inherited values apply everywhere: in the recorded event, in the rule's conditions, and in the [analyses](/en/rules/analyses/).

Sending the field with the value `null` clears the inherited value, and later posts do not recover it. Omitting the field keeps the inheritance.

Inheritance has a deadline, configured in the event type. Once that deadline passes with no new posts under the same `id`, the platform discards the accumulated values and a later post holds exactly for what it carries.

## Submission validation

Event validation follows the event type configuration:

* required fields must be sent;
* data types must be in the expected format;
* unknown fields can be ignored or rejected, depending on the event type configuration.

The validation ensures consistency in ingestion and prevents out-of-contract events from affecting metrics and monitors.

## Submission response

The response presents the event's `id` and every field of the event type. The fields **filled in by a rule** during processing also appear in the response. An event sent with three fields can return with five, if a rule enriched the other two.

The platform records the reserved fields in the event but does not present them in the response.

## Practical example

1. You register an event type with ID `transaction`.
2. Define the expected fields, such as `amount` and `status`.
3. Send an event to `POST /events` with `type: transaction`.
4. The platform validates the payload, runs the event type's rule (if there is one), and processes the event for use in analyses, metrics, and monitors.