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.
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

Select a project to expand it and see its features.
Select a feature to see the endpoints grouped under it.
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
Edit parameters, request body, headers, and assertions — Test case
Run a test and see the result — Test run
Validate that the endpoint resolves and responds — Validate endpoints

For adding, editing, or removing endpoints themselves rather than testing them, see 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.

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.

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 and 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.
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.

Managing Projects and Endpoints