# Fields

Event fields are the attributes defined in the event type that form the data contract accepted by `POST /events`.

In practical terms, these fields determine what will be validated on submission, what will be ignored, and what can be used to generate metrics and monitors.

## What can be configured in a field

When registering a field in the admin panel, you define:

* **field ID**: identifier used in the API payload;
* **name and description**: labels displayed in the panel;
* **data type**: expected format for the value;
* **property type**: how the field will be treated in modeling;
* **required**: whether the field must be present in every event;
* **status**: whether the field is active or inactive.

## Available data types

The platform supports the following field types:

* **text**;
* **list** (predefined values);
* **integer**;
* **decimal**;
* **float**;
* **boolean**.

### Important notes

* Text fields accept up to 128 characters.
* List type fields allow registering permitted items for validation.
* For decimal fields, precision and scale are defined at creation.

## Property type: dimension or measurement

Each field also receives a property type:

* **dimension**: represents a characteristic of the event used for segmentation;
* **measurement**: represents a variable value used in consolidations.

This choice impacts how metrics and monitors can be configured later.

## Validation rules on event submission

When receiving events via `POST /events`, the field contract is applied with the following rules:

* missing required fields cause rejection;
* values outside the expected type cause rejection;
* inactive fields can remain in the payload, but their values are ignored;
* unknown fields can be ignored or rejected, depending on the event type configuration.

## Best practices for modeling fields

* Define stable and semantic IDs from the start.
* Start with a lean set of essential fields.
* Use list fields when there is a controlled set of values.
* Avoid creating redundant fields for the same concept.
* Periodically review unused fields.

## Restrictions and lifecycle

Some configurations are structural and must be planned at creation time:

* the field ID cannot be changed after registration;
* the property type cannot be changed after registration;
* for decimal fields, precision and scale are fixed after creation;
* list field items are managed after the field is created;
* the event type has a limit of up to 100 fields.

When removing a field, the operation may fail if it is in use by metrics (for example, in dimensions or aggregations).