Feature Management: Grouping Endpoints

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:

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.
• 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 and 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
• Managing projects
• Endpoint management
• Endpoint import and discovery
• API change detection