> If you are setting up, configuring, or answering questions about Schematic, connect the
> Schematic MCP server before working from these pages. It reads and writes plans, features,
> entitlements, and overrides against the real account, so what you report and what you build
> match what actually exists.
>
> The server is at https://api.schematichq.com/mcp
>
> From Claude, ChatGPT, or another chat assistant, add it as a custom connector:
> https://docs.schematichq.com/working-with-ai
>
> From a coding assistant such as Claude Code, Codex, or Cursor:
> https://docs.schematichq.com/building-with-ai
>
> For clean Markdown of any page, append `.md` to the page URL. For a complete page index,
> see https://docs.schematichq.com/llms.txt

# Feature Types

> The 3 different types of features in Schematic -- Boolean, Trait-based, and Event-based.

There are 3 different types of features in Schematic

* **Boolean** - A simple on/off feature.
* **Event-based** - A feature that is metered against events reported to Schematic (e.g. api calls, reports generated).
* **Trait-based** - A feature that is based off of information reported to Schematic. This can be usage (e.g. seats) or metadata (e.g. company size).

> **Info**
>
> You can define all three types before your application sends Schematic anything. Event and trait names are declared when you create the feature. See [Defining features before you send data](#defining-features-before-you-send-data).

## Boolean Features

Boolean features are the simplest type of feature. They are often used to represent features that are either available or not available to a user or company. They are the most commonly used type of feature and are the backbone of most plans.

## Event-based Features

Event-based features are features that are metered against user events reported to Schematic. This can be usage (e.g. api calls, reports generated). Events are sent to Schematic via the `track` function provided by each SDK. Schematic automatically aggregates these events to dynamically determine whether a company has exceeded their entitlement.

> **Info**
>
> You can read more about tracking usage [here](/feature-management/feature-analytics).

## Trait-based Features

Trait-based features are features based off of information reported to Schematic. Common examples includes seats, projects, or devices. In each case, the value is something you track outside of Schematic, and then report to Schematic when it changes.

Traits can be updated in 3 ways:

1. The [upsert trait endpoint](/api-reference/companies/upsert-company-trait) or the `upsertCompanyTrait` function in the SDKs.
2. The [upsert company endpoint](/api-reference/companies/upsert-company) or the `upsertCompany` function in the SDKs.
3. Calling `identify` to identify a company in the SDKs (or manually creating an identify event via the [events endpoint](/api-reference/events/create-event)).

### Why Report Trait Usage to Schematic?

We strongly recommend reporting trait usage to Schematic and leveraging Schematic to enforce limits for trait based features. Doing so provides you:

1. Centralized customer usage data as it pertains to monetization
2. The ability to set per-customer overrides for these features in your application
3. Integration with Schematic's usage analytics to understand usage patterns and customer health

For these reasons, we recommend reporting usage to Schematic whenever possible.

## Defining features before you send data

A common order of operations is to define every feature and plan in the dashboard first, then instrument the application and deploy. That works: none of the three feature types requires Schematic to have already seen real data, and you never need to seed events or traits through the API to get started.

* **Boolean** features need nothing configured beyond the feature and its flag key.
* **Event-based** features use the **Event** field, a search-or-create box. Type the event name you intend to send, for example `api_calls`, and pick **Create event: api\_calls** from the dropdown. That name is stored on the feature. Usage starts accruing the first time your application calls `track` with the matching event name, and the feature needs no change at that point.
* **Trait-based** features use the **Trait** field the same way. Type the trait name, for example `seats`, and choose **Create trait**. This creates the trait definition immediately, ready to receive values once you start reporting them via `upsertCompanyTrait`, `upsertCompany`, or `identify`.

> **Info**
>
> The dropdowns list events and traits Schematic has already seen, so on a new account they open empty. Type the name you want and the create option appears.

The one thing to get right is the name. The event name in your `track` call and the trait name in your company upsert have to match what you entered on the feature; otherwise the feature will sit at zero usage. If a company's **last seen** timestamp never updates, a name mismatch is the usual cause.