# Feature Management: Grouping Endpoints

> Features group endpoints and come from your spec's tags. Covers creating and editing by hand, why tagging matters, and what deleting a feature takes with it.

Source: https://totalshiftleft.ai/help-center/product-documentation/feature-management

## Overview

A **feature** groups endpoints inside a project. It's the middle level of the tree:

**Project → Feature → Endpoint**

Features exist to keep a large API navigable. An API with 200 endpoints and no grouping is a scrolling exercise; the same API grouped into `Orders`, `Payments`, and `Customers` is something you can work in.

## Where features come from

Features are generated from the **tags** in your API specification. Tag your operations `Orders` and `Payments`, and you get two features with those names and those operations under them.

This has a consequence people meet on their first import: **an untagged spec produces one flat feature.** Every endpoint lands in the same bucket, and no amount of clicking in the product will improve it. That isn't the importer misbehaving — it's a faithful reflection of a specification that doesn't say how its operations relate.

The fix belongs in the spec. Add tags, re-import, and the structure appears. It's worth doing once: the tags also organize your API documentation, so the effort pays off in two places.

## Creating a feature by hand

You can create features manually:

| Field | What to enter |
|-------|---------------|
| **Name** | The feature name, e.g. `Orders`. |
| **Description** | A short summary of its scope. |

This is the right tool when you're testing operations that aren't in a spec, or when you want a grouping the spec doesn't express. It's the wrong tool for working around an untagged spec — hand-built features drift from the contract the moment the API changes, and the next re-import won't know about them.

Rule of thumb: if the grouping *should* exist in your API contract, put it in the contract.

## Editing a feature

Name and description are editable. Keep names aligned with your API's domain boundaries — feature names show up in navigation and reports, so a vague name costs a small amount of confusion many times over.

Consistency matters more than elegance. `Orders`, `Payments`, `Customers` beats `Order Management`, `payments-api`, `Customer Stuff`, even though any one of those is fine in isolation.

## Deleting a feature

**Delete Feature** removes the feature — **and the endpoints grouped under it, and their tests.** It isn't a soft delete, and the blast radius is larger than the thing you clicked on.

Before deleting, check which case you're in:

- **The feature was created in error, or its operations are gone from the API** — delete it.
- **You want to stop running its tests for now** — don't delete. Leave it and exclude those tests from your pack instead. See [Test run pack wizard](/help-center/product-documentation/test-run-pack-wizard).
- **The import produced bad structure** — fix the tags in the spec and re-import rather than pruning by hand.

Deleting a feature to tidy a tree is one of the easier ways to lose coverage without anyone deciding to remove it.

## Keeping features aligned

When your API changes, re-import and let change detection tell you what moved. See [API change detection](/help-center/product-documentation/api-change-detection) and [Project operations](/help-center/product-documentation/project-operations).

If a feature disappears after a re-import, its tag is gone from the spec — that's the contract telling you something changed, not data loss.

## Best practices

- **Tag your specification.** It's the single highest-leverage thing for a usable tree, and it's upstream of the product entirely.
- **One feature per domain boundary**, matching how your team already talks about the API.
- **Keep names consistent** across projects. Reports read better.
- **Prefer re-importing to hand-editing.** The tree should be a projection of the contract; every manual edit is drift.

## Troubleshooting

- **Every endpoint is in one feature** — your spec has no tags. Add them and re-import.
- **Feature names look wrong or inconsistent** — they're your spec's tags. Fix them at the source.
- **A feature vanished after re-import** — its tag is no longer in the spec.
- **You deleted a feature and lost tests** — deletion cascades to endpoints and their tests, and isn't reversible. Restore from an export if you have one.
- **A hand-made feature disappeared** — re-imports reconcile against the spec; groupings that exist only in the product don't survive well.

## Related articles

- [Project](/help-center/product-documentation/project)
- [Managing projects](/help-center/product-documentation/managing-projects)
- [Endpoint management](/help-center/product-documentation/endpoint-management)
- [Endpoint import and discovery](/help-center/product-documentation/endpoint-import-and-discovery)
- [API change detection](/help-center/product-documentation/api-change-detection)