---
title: Features
description: The three kinds of entitlement, and the codes your app checks.
domain: entitlement
status: shipped
visibility: public
last_verified: 2026-07-11
order: 10
---
A feature is one thing a plan can grant. You define your features in a catalog, and each one has a code and a kind. The code is a stable key your application checks; the kind decides how the feature is enforced.

## Codes

Every feature has a code, a short stable key like `seats`, `workflows.active`, or `ai.copilot`. Your application gates on the code, never on a plan name. That way you can rename or restructure plans without touching the code that checks entitlements.

## The three kinds

| Kind | What it is | Example |
|---|---|---|
| Switch | A feature that is on or off. | Access to the API, a premium report. |
| Limit | A cap on how many of something a customer can hold at once. | Seats, projects, active workflows. |
| Quota | An allowance used up over a period, then reset. | AI copilot questions per month. |

A switch holds a yes or no. A limit and a quota both hold a number, but they behave differently: a limit caps a running total that goes up and down as things are added and removed, while a quota is consumed over a period and starts fresh each period.

## Quotas reset on a period

Because a quota is an allowance, it needs a period to reset on: a day, a week, or a month. "500 copilot questions per month" is a quota with a monthly reset. When the period turns over, the allowance is full again.

## In the API

Manage your feature catalog through the `POST /v1/features` endpoint and the rest of the `/v1/features` routes. See the [API reference](/reference). Attaching features to plans is on the [next page](/guide/entitlements/how-entitlements-resolve).

## Edge cases

- **Gate on codes, not plan names.** The code is the stable thing; plans change.
- **A switch is a yes or no; a limit and a quota are numbers.** The kind decides which.
- **Only quotas reset.** A limit is a standing cap, not something that refills.