> ## 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. See how requests become reusable tests. # 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, whether it has test coverage, and how its definition has changed over time. ## Where to find it Open **API** under **Context** in the sidebar. The page is titled **API governance**. Pick a collection from the dropdown at the top right; the page remembers it in the URL, so a reload returns to the same collection. The list loads 50 endpoints at a time and loads more as you scroll. The count line above the table says how many endpoints match the current filters, for example "59 of 3,134 endpoints, showing 50". Each row shows the method, name, path, auth, findings, PII, tests, when the definition last changed, and the last run status. ![API governance page with the coverage bar, summary line, Auth, Security tests, Open findings, and Sensitive data tiles, filters, and the endpoint list](https://mintcdn.com/qodexai/8H5N-Qajjdx9V4Gb/images/docs/api-testing/api-governance.png?fit=max\&auto=format\&n=8H5N-Qajjdx9V4Gb\&q=85\&s=b02cd4fe17488c6d1c0dd8422ae5faf1) ## 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, sensitive data fields detected, security issues observed. * **Coverage signals**: test count, passing tests, failing tests, last tested timestamp. * **Lifecycle and history**: whether the endpoint is active, deprecated, or removed, and a log of every definition change. The same row backs four surfaces: the catalog list, the API details panel, the API Playground, and the agent's endpoint tools. Edit anywhere and the other surfaces stay in sync. ## Filtering The filter row under the summary tiles narrows the list: | Control | What it does | | - | - | | **All / Covered / Uncovered** | Show every endpoint, only endpoints touched by at least one scenario, or only endpoints with no scenarios. | | **Risk** | A menu that combines risk filters: **Auth** (Without known auth, Requires auth, Needs none), **Security tests** (No security test, Tested), **Last run** (Failing, Errored, Never run), **Findings** (Open findings, optionally by severity), and **Sensitive data** (Returned sensitive data, optionally by kind such as email or credit card). | | **Method** | One or more HTTP methods. | | **Tag** | Scope to one module, such as `auth`, `users`, or `billing`. Tags come from the spec (`tags[]`) or from Postman folder names. | | **Changed** | Only endpoints whose definition changed in the last 24 hours, 7 days, or 30 days. Once a window is set, a second dropdown narrows it to **Added** or **Changed** endpoints. | | **Sort** | Gaps first (the default), worst findings first, recently changed, or path. | | **Search APIs...** | Free-text search across the collection. | Filters stack. For example, open **Risk**, pick **Requires auth** and **No security test**, then set **Tag** to `users` to find protected user endpoints with no security coverage. Every active filter appears as a chip next to the count line. Click the **x** on a chip to clear that filter, or **Clear all** to reset. Filters are stored in the page URL, so you can share a link to a filtered list. The four summary tiles above the filters (**Auth**, **Security tests**, **Open findings**, **Sensitive data**) are shortcuts. Clicking a number clears the other filters and shows exactly those endpoints; clicking it again clears it. See [API governance](https://qodex.ai/docs/api-testing-governance.md) for what each tile counts. ## The API details panel Click a row to open the **API details** panel. Its header holds **Open in playground**, the lifecycle actions, and **Generate tests**. The panel has five tabs: | Tab | Shows | | - | - | | **Overview** | The description (from the spec, the operation summary, or the name), team notes and Qodex observations, security details (declared and observed authentication, possible PII fields, missing security headers, open findings), and test coverage. | | **Request** | Path and query parameters plus a captured request from a test run, or the request body schema from the spec. If the endpoint was edited and saved in the Playground, this tab shows that saved request instead. | | **Response** | A captured response from a test run, or the response schema from the spec. | | **Tests** | Every scenario that touches the endpoint, with its last result and priority. If none do, use **Generate tests**. | | **History** | The endpoint's definition changes. See [Change history](#change-history). | An **Edited** badge in the panel header means the request was changed and saved in the Playground. ### Team notes and Qodex observations The Overview tab keeps two kinds of notes apart: * **Team notes** are written or approved by people on the project. Qodex treats them as rules it may cite. Click **Edit** to write them, one rule per line. * **Qodex observations** are what Qodex saw in earlier runs. Nobody has confirmed them, so Qodex uses them as context and never as a rule. Click **Approve** next to an observation to move it into team notes. ## Editing requests Request fields (params, headers, body, and auth) are edited in the [API Playground](https://qodex.ai/docs/api-testing-playground.md), which works on the same row. The request editor supports: * **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`. Saved edits set the row's 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** in the API details panel to land at `/p//playground/` with the live request form prefilled. There is no copy-paste step because the catalog and Playground edit the same row. The **Open playground** button in the page header opens an empty request instead. From the Playground you can: * Hit **Send** to fire the request against the active environment. * Edit the request and save it back to the catalog row. To turn an endpoint into tests, click **Generate tests** in the API details panel. Qodex opens a chat scoped to that endpoint and authors scenarios for it. ## Endpoint lifecycle Every endpoint has a lifecycle state: | State | Meaning | | - | - | | **Active** | The endpoint is served. This is the default list, and only active endpoints count toward coverage. | | **Deprecated** | The code the catalog is synced from no longer declares the endpoint, or someone marked it deprecated. The row, its scenarios, and its history stay, and its tests keep running. | | **Removed** | Someone took the endpoint out of the catalog. Nothing is deleted. | To change the state, open the endpoint's details panel: * On an active endpoint, click **Deprecate** or **Remove**. * On a deprecated endpoint, click **Restore** to make it active again, or **Remove**. * On a removed endpoint, click **Restore** to put it back exactly as it was. None of these actions ask for confirmation, because every change can be reversed. **Generate tests** is only offered on active endpoints. When a collection has deprecated or removed endpoints, the summary line under the coverage bar shows **N deprecated** and **N removed**. Click either one to list those endpoints; click it again to return to the active list. They are counted separately so an API that shrank does not look like a suite that got worse. ## Change history The **History** tab lists every change to an endpoint's definition, newest first: * What happened, such as added to the catalog, imported, changed fields, marked deprecated, removed, or restored. * Who or what made the change: a person, collection sync, a spec import, a collection merge, discovery, the Playground, the catalog, or chat. * When it happened. Click an entry to see the field-level change, before and after. Long or sensitive values are shown as a short preview with their length rather than in full. Click **Show older** to load earlier entries. History records definition changes only; test results stay on the **Tests** tab. To find endpoints that moved recently across the whole collection, use the **Changed** filter or sort by **Recently changed**. The **Changed** column shows how long ago each endpoint's definition last changed. ## Delete a collection Project admins can permanently remove an imported or discovered API collection: 1. Open **API** under **Context** in the sidebar. 2. Select the collection in the collection dropdown. 3. Click **Delete collection** next to the dropdown. 4. In the **Delete this collection?** dialog, type the collection name to confirm. 5. Click **Delete collection**. > [!WARNING] > > Deleting a collection also removes all of its endpoints and every endpoint's change history. This cannot be undone. Qodex refuses to delete a collection that a repository's code sync writes into. The dialog shows the reason; change the sync target first, then delete. The button is not shown to members who are not admins. ## How endpoints land in the catalog Four sources: 1. **Spec import**: every HTTP operation under OpenAPI `paths` or every Postman request. 2. **Auto-discovery**: the deterministic crawler captures every API call your UI fires. 3. **Chat**: paste a cURL command and ask the agent to add it to a collection. 4. **Manual creation**: click **+ New** in the Playground to create an ad-hoc request. Saved requests land in the project's per-project "Default" collection so they're still queryable in the catalog. All sources produce identical row shapes. The agent doesn't distinguish "imported" from "discovered" from "ad-hoc" when reading the catalog. ## Manage collections from chat You can organize collections by asking the agent in chat: ```text theme={null} Create a collection called Payments and add this request to it: curl -X POST https://staging.example.com/api/refunds -H "Content-Type: application/json" -d '{"orderId": "123"}' ``` ```text theme={null} Remove DELETE /users/{id} from the Admin collection. ``` The agent can create a collection, add an endpoint from a pasted cURL, remove an endpoint, rename a collection, and merge two collections. ## Keep the catalog in sync Use a [collection sync mission](https://qodex.ai/docs/missions.md) when the API keeps changing after the first import. The first sync can build a clean baseline from the current collection. Later syncs focus on changed endpoints, new routes, removed routes, and request shapes that need review. An endpoint the synced code no longer declares becomes **Deprecated**, and the change shows up in its history. After a sync, set the **Changed** filter to the last 24 hours or 7 days to review what moved, open important rows in the Playground, and promote stable requests into scenarios. If a synced endpoint has not been confirmed by a person yet, treat it as a candidate row: review its URL, params, headers, body, and auth before using it in a scheduled run or merge gate. ## 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. * Reviewing API changes: the history and **Changed** filter show what moved and who moved it. * 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. ## Related > [card] [API governance](https://qodex.ai/docs/api-testing-governance.md) > > Coverage view over the same catalog. > [card] [API Playground](https://qodex.ai/docs/api-testing-playground.md) > > Edit and run a single row. > [card] [Import an OpenAPI spec](https://qodex.ai/docs/api-testing-openapi-import.md) > > Populate the catalog from a spec. > [card] [Import a Postman collection](https://qodex.ai/docs/api-testing-postman-import.md) > > Populate the catalog from Postman. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.