> ## Documentation Index
> Fetch the complete documentation index at: https://qodex.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Endpoint catalog

> The endpoint catalog is the editable source of truth for every API endpoint Qodex knows about.

# Endpoint catalog

The endpoint catalog is the map of your API inside Qodex.

It shows every endpoint Qodex knows about, where it came from, what auth and request shape it uses, and whether it has test coverage.

## How it works

Every endpoint lives as one editable row. That row carries:

* **Spec-derived fields**: method, path, summary, operation ID, tags, request schema, response schema, parameters.
* **Playground-owned fields**: a user-set name, full URL with `{{var}}` tokens, headers, params, body, settings, auth.
* **Discovery fields**: observed auth type, missing security headers, PII fields detected, security issues observed.
* **Coverage signals**: test count, passing tests, failing tests, last tested timestamp.

The same row backs four surfaces: the catalog list, the catalog detail panel, the API Playground, and the agent's endpoint tools. Edit anywhere and the other surfaces stay in sync.

## Filtering

The catalog supports filtering by:

| Filter          | What it does                                                                                                      |
| --------------- | ----------------------------------------------------------------------------------------------------------------- |
| **Tag**         | Scope to one module: `auth`, `users`, `billing`. Tags come from the spec (`tags[]`) or from Postman folder names. |
| **Role**        | Scope to endpoints scenarios cover under a specific auth profile (`admin`, `user`, `viewer`).                     |
| **Coverage**    | Tested, untested, or failing. See [API governance](/api-testing-governance) for definitions.                      |
| **Auth status** | `required`, `none`, or `unknown` (derived from spec tags and observed traffic).                                   |
| **Findings**    | Endpoints with at least one open finding tied to a covering scenario.                                             |

You can stack filters freely. For example, filter to auth-required `users` endpoints with zero scenarios and at least one critical finding.

## The editable row

Every row in the catalog can be edited inline. Open the detail panel to see the same request tabs used by the API Playground:

* **Params**: query and path parameters as a key-value grid.
* **Headers**: request headers, enabled or disabled per row.
* **Body**: one of `none`, `json`, `text`, `xml`, `form-urlencoded`, `multipart`, `binary`, `graphql`.
* **Auth**: `none`, `inherit` (from collection default), `basic`, `bearer`, or `apiKey`.

Edits set the row's `is_edited` flag. Re-importing the spec preserves your edits on request fields. Spec-only fields, such as summary, parameters, and schemas, refresh on re-import.

## Opening an endpoint in the Playground

Click **Open in Playground** on any row to land at `/p/<slug>/playground/<endpointId>` with the live request form prefilled. There is no copy-paste step because the catalog and Playground edit the same row.

From the Playground you can:

* Hit **Send** to fire the request against the active environment.
* Click **Save as scenario** to promote the request into a new API scenario.
* Edit and save back to the catalog row.

## How endpoints land in the catalog

Three sources, in order of frequency:

1. **Spec import**: every operation under OpenAPI `paths` or every Postman request.
2. **Auto-discovery**: the deterministic crawler captures every API call your UI fires.
3. **Manual creation**: hit **+ New** in the Playground to create an ad-hoc endpoint. It lands in the project's per-project "Default" collection so it's still queryable in the catalog.

All three paths produce identical row shapes. The agent doesn't distinguish "imported" from "discovered" from "ad-hoc" when reading the catalog.

## When this matters

* Authoring scenarios: the agent reads the catalog row to know what params, headers, and auth an endpoint expects.
* Reviewing imports: after importing a spec, the catalog is your sanity check for endpoints, tags, and auth.
* Onboarding: the catalog is the first-pass map of what the API does.

## On the roadmap

<Tip>
  Per-operation GraphQL rows are already live (each operation under `POST /graphql` is its own row). Phase 2 brings cookie jar UI for cookie-based endpoints and a folder-level batch runner that fires every endpoint in a tag.
</Tip>

## Related

<CardGroup cols={2}>
  <Card title="API governance" icon="map" href="/api-testing-governance">
    Coverage view over the same catalog.
  </Card>

  <Card title="API Playground" icon="terminal" href="/api-testing-playground">
    Edit and run a single row.
  </Card>

  <Card title="Import an OpenAPI spec" icon="file-code" href="/api-testing-openapi-import">
    Populate the catalog from a spec.
  </Card>

  <Card title="Import a Postman collection" icon="folder-input" href="/api-testing-postman-import">
    Populate the catalog from Postman.
  </Card>
</CardGroup>