# Managing Projects and Endpoints

> Navigate the project → feature → endpoint tree in the sidebar: search and filter projects, open features, select endpoints, and reach the test workflow.

Source: https://totalshiftleft.ai/help-center/product-documentation/managing-projects

## Overview

Once you've imported an API definition, Shift-Left API organizes it into a tree in the left sidebar. Everything you do with tests starts by navigating that tree to an endpoint.

| Level | What it is | Where it comes from |
|-------|------------|---------------------|
| **Project** | The workspace. | You create it. |
| **Feature** | A group of endpoints. | The tags or groups in your API specification. |
| **Endpoint** | One operation — method plus path, such as `GET /orders/{id}`. | The operations in your specification. |

Tests attach to endpoints. Features exist to keep the endpoint list navigable — a spec with no tags produces a flatter tree.

## Finding your way around

The sidebar is the primary navigation:

- **Search projects…** filters the project list as you type.
- **Filter projects by workspace** narrows to a single workspace when you have several.
- **Add Project** creates a new project — see [Project](/help-center/product-documentation/project).
- **Collapse sidebar** / **Expand sidebar** reclaims screen space when you're working in a report. You can drag the sidebar edge to resize it, and **double-click to reset width** if you've dragged it somewhere unhelpful.

## Working through the tree

1. Select a **project** to expand it and see its features.
2. Select a **feature** to see the endpoints grouped under it.
3. Select an **endpoint** to open it and reach its tests.

Endpoint rows show the HTTP method (`GET`, `POST`, `PUT`, `DELETE`, and so on) and the path, so you can identify an operation without opening it.

## What you can do from an endpoint

Opening an endpoint is the entry point to the core loop:

- **Generate** tests from the endpoint definition — [AI-generated tests](/help-center/product-documentation/ai-generated-tests)
- **Edit** parameters, request body, headers, and assertions — [Test case](/help-center/product-documentation/test-case)
- **Run** a test and see the result — [Test run](/help-center/product-documentation/test-run)
- **Validate** that the endpoint resolves and responds — [Validate endpoints](/help-center/product-documentation/validate-endpoints)

For adding, editing, or removing endpoints themselves rather than testing them, see [Endpoint management](/help-center/product-documentation/endpoint-management).

## Deleting features and endpoints

**Delete Feature** and **Delete Endpoint** are available on the relevant tree nodes.

Deleting an endpoint takes its tests with it. Deleting a feature takes the endpoints grouped under it — and their tests. Neither is a soft delete, so prefer re-importing a corrected spec over pruning the tree by hand when the goal is to fix a bad import.

A useful distinction: if the endpoint no longer exists in your API, delete it. If it exists but you don't want to test it right now, leave it and just don't include it in a pack — see [Test run pack wizard](/help-center/product-documentation/test-run-pack-wizard).

## Why the tree looks the way it does

The shape of your tree is decided by your specification, not by the product, and that surprises people often enough to be worth stating plainly.

**Features come from tags.** In an OpenAPI document, the `tags` on each operation become features. Tag your operations `orders`, `payments`, and `customers`, and you get three features. Tag nothing, and every endpoint lands in one flat group. If your tree is an undifferentiated list of 200 endpoints, the fix is in your spec — add tags and re-import.

**One operation becomes one endpoint.** `GET /orders/{id}` and `DELETE /orders/{id}` share a path but are separate operations, so they're separate endpoints with separate tests. That's usually what you want: the assertions for reading an order have little to do with deleting one.

**Path parameters stay symbolic.** The tree shows `/orders/{id}`, not `/orders/123`. The concrete value is supplied at test time, from test data or a variable — see [Data-driven testing](/help-center/product-documentation/data-driven-testing).

This means the tree is a faithful projection of your contract. When it looks wrong, the contract is usually where to look first — which is a feature, not an annoyance, because a tree that disagreed with your spec would be worse.

## Keeping the tree current

Your API will move. Re-importing an updated specification is the normal way to stay aligned, and change detection tells you what actually changed rather than making you diff by eye. See [API change detection](/help-center/product-documentation/api-change-detection) and [Project operations](/help-center/product-documentation/project-operations).

After a significant spec change, re-check the tests on any endpoint whose request or response model moved.

## Troubleshooting

- **"Failed to load project settings."** — the project's settings couldn't be fetched. Reload; if it persists, see [Debug logging](/help-center/product-documentation/debug-logging).
- **A project isn't in the list** — check the workspace filter before assuming it's gone; it may simply be in a workspace you've filtered out.
- **Endpoints landed in one big undifferentiated feature** — your specification has no tags or groups to organize by. That's a property of the spec, not the import.
- **An endpoint you expected isn't in the tree** — it wasn't in the imported document. Re-check the source spec rather than adding it by hand, so the project stays a faithful reflection of the contract.

## Related articles

- [Project](/help-center/product-documentation/project)
- [Project operations](/help-center/product-documentation/project-operations)
- [Project settings](/help-center/product-documentation/project-settings)
- [Endpoint management](/help-center/product-documentation/endpoint-management)
- [Validate endpoints](/help-center/product-documentation/validate-endpoints)