> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usertour.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Attributes

> Custom attributes on users, companies, and events — naming and data types.

Users, companies, and events carry custom **attributes** that extend the default
data model. The schema of your attributes is exposed by the **attribute
definitions** endpoint (`attribute:read`); the values live on each user/company
object.

## Naming

A `codeName` created through the API must start with a letter and contain only
letters, digits, and underscores, 2–100 characters (`snake_case` is the
convention — `signed_up_at`, `last_login_time`). It is case-sensitive and unique
per scope. SDK ingestion is deliberately more lenient: an attribute key your app
sends that isn't defined yet is **auto-created** with a type inferred from the
first value — so send a number as `42` (not `"42"`) and dates as full ISO
timestamps; a wrongly inferred type can be corrected later while no stored value
conflicts.

Display names (shown in the Usertour UI) are configured separately — e.g.
`signed_up_at` can display as "Signed Up".

## Data types

| Type       | Description                       |
| ---------- | --------------------------------- |
| `string`   | A string.                         |
| `number`   | Integer or floating point.        |
| `boolean`  | `true` or `false`.                |
| `datetime` | A point in time, ISO 8601 in UTC. |
| `list`     | A list of strings.                |

## Best practices

* Use the most specific type — store dates as `datetime`, flags as `boolean`
  (not strings).
* Keep names concise but descriptive; avoid system/reserved names.
* Don't store large blobs in attributes.