# Endpoint Management: Select and Maintain

> Find endpoints by method and path, add or edit them by hand, try a request for debugging, and know when to re-import instead of editing the tree manually.

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

## Overview

An **endpoint** is one operation on your API — a method and a path, such as `GET /orders/{id}`. Endpoints are where tests live, so most work starts by finding the right one.

Endpoints normally arrive by importing your API specification rather than being typed in. See [Endpoint import and discovery](/help-center/product-documentation/endpoint-import-and-discovery).

A project with nothing imported yet shows **No endpoints yet**.

## Finding an endpoint

Endpoints are grouped under **Features**, which come from the tags in your specification. Select a feature to see its endpoints, then select an endpoint to open it.

**Search endpoints…** filters the list, which is the faster route on a large API.

## Endpoint actions

| Action | What it does |
|--------|--------------|
| **Edit Endpoint** | Change the endpoint's definition. |
| **Copy Endpoint** | Duplicate it, as a starting point for a variant. |
| **Delete Endpoint** | Remove it — and its tests. |
| **Try request (debug)** | Send a one-off request and see the raw response, without creating a test. |

### Try request (debug)

**Try request (debug)** is the fastest way to answer "is it my test, or is it the API?" It sends the request now and shows you what came back.

Reach for it when a test fails and you're not sure whether the assertion is wrong or the endpoint is genuinely broken — it separates those two cases in one click, instead of by editing a test repeatedly.

For a systematic check across endpoints rather than one at a time, use [Validate endpoints](/help-center/product-documentation/validate-endpoints).

## Adding or editing an endpoint by hand

Endpoints can be created and edited manually:

| Field | What it is |
|-------|------------|
| **Name** | A readable name for the operation. |
| **Method** | The HTTP method — `GET`, `POST`, `PUT`, `DELETE`, and so on. |
| **URL** | The path, relative to the environment's base URL. |
| **Description** | What the operation does. |

Keep the **URL** as a path with symbolic parameters (`/orders/{id}`), not a full URL with a host. The host comes from the environment's base URL in [Project settings](/help-center/product-documentation/project-settings) — hardcoding it here is what makes an endpoint work in one environment and fail in every other.

SOAP endpoints use a **SOAP Endpoint URL** rather than a REST-style path.

## When to edit by hand, and when to re-import

Manual editing is available, but it's usually the wrong tool. Your endpoint tree is a projection of your API contract, and hand-edits make it drift from that contract silently.

**Re-import** when:
- The API changed and the spec reflects it. Re-importing keeps the tree faithful and tells you what moved. See [API change detection](/help-center/product-documentation/api-change-detection).
- An endpoint is missing. It's almost always missing from the spec too — fix it there, not here.
- The import produced something wrong. Correct the source document and import again.

**Edit by hand** when:
- You're testing something genuinely not in the spec — an undocumented operation you still need coverage on.
- You need a variant of an existing endpoint for a specific test scenario. **Copy Endpoint**, then adjust.

The rule of thumb: if the change *should* exist in your API contract, put it in the contract. Hand-editing to work around a stale spec means your tests and your documentation disagree, and the tests will quietly win until someone notices.

## Deleting endpoints

**Delete Endpoint** takes the endpoint's tests with it, and it isn't a soft delete.

Before deleting, check which case you're in:

- **The operation no longer exists in your API** — delete it. Keeping it produces permanent failures.
- **The operation exists but you don't want to run it right now** — don't delete. Just leave it out of the pack. See [Test run pack wizard](/help-center/product-documentation/test-run-pack-wizard).

Deleting to silence a failing test is how coverage disappears without anyone deciding to remove it.

## Troubleshooting

- **"No endpoints yet"** — nothing has been imported. See [Project operations](/help-center/product-documentation/project-operations).
- **An endpoint returns 404 in tests but works in your browser** — the **URL** likely includes a host, or the environment's base URL is wrong. Check both.
- **All endpoints in one flat feature** — your specification has no tags. Add them and re-import.
- **An endpoint disappeared after re-import** — it's gone from the spec. That's change detection working, not data loss. See [API change detection](/help-center/product-documentation/api-change-detection).
- **Try request works but the test fails** — the endpoint is fine and the assertion or test data is wrong. Open the test — see [Test case](/help-center/product-documentation/test-case).

## Related articles

- [Endpoint import and discovery](/help-center/product-documentation/endpoint-import-and-discovery)
- [Managing projects](/help-center/product-documentation/managing-projects)
- [Validate endpoints](/help-center/product-documentation/validate-endpoints)
- [Test case](/help-center/product-documentation/test-case)
- [API change detection](/help-center/product-documentation/api-change-detection)