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

# API governance

> Track API coverage across every endpoint Qodex has seen and fill gaps with generated scenarios. Use the coverage view to find and close gaps.

# API governance

API governance shows API coverage across every endpoint Qodex knows about.

Use it to answer practical questions: which endpoints are tested, which are untested, which are failing, and where Qodex should generate more coverage.

## Where to find it

Open **API** under **Context** in the sidebar and pick a collection from the dropdown at the top right. The **API governance** page shows the collection's coverage bar, a summary line, four risk tiles, and the filterable endpoint list.

If the project has no API collection yet, the page shows **No API spec yet** with an **Add a spec** button that opens the spec import step.

![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

Governance reads the same endpoint rows used by imports, the endpoint catalog, the API Playground, and discovery. There is no separate coverage database, so the catalog you see and the numbers the agent uses stay aligned.

The top of the page summarizes the collection:

* **Coverage bar**: the percentage of active endpoints touched by at least one scenario.
* **Summary line**: endpoints, covered, uncovered, and tests. When the collection has deprecated or removed endpoints, **N deprecated** and **N removed** appear here too; click either to list them.
* **Cover N gaps**: shown when some endpoints have no scenarios. It opens chat so you can confirm and start a coverage run for those endpoints.

Every count is over active endpoints only. Deprecated and removed endpoints are counted on their own, never against coverage, so an API that shrank does not read as a suite that got worse. See [Endpoint lifecycle](https://qodex.ai/docs/api-testing-endpoint-catalog.md#endpoint-lifecycle).

For every endpoint, the list shows:

* Method, name, and path.
* Auth: required, none, or unknown, with a warning when declared and observed auth disagree.
* Open findings tied to the endpoint, by severity.
* Sensitive data the endpoint returned in a captured response.
* Tests: the number of scenarios covering it.
* Changed: how long ago the endpoint's definition last changed.
* Status: whether the last run passed, failed, or errored, or `none` when nothing covers it.

Click a row for the API details panel with security details, covering scenarios, and change history.

## The risk tiles

Four tiles sit above the list. Each headline and secondary number is a count of endpoints, and clicking a number filters the list to exactly those endpoints (it clears other filters first). Click the same number again to clear it.

| Tile | Headline | Secondary numbers |
| - | - | - |
| **Auth** | Endpoints without known auth | Require auth, need none |
| **Security tests** | Endpoints with no security test (a scenario tagged security, injection, IDOR, or XSS) | Tested |
| **Open findings** | Endpoints with at least one open finding | One number per severity, plus the total findings count |
| **Sensitive data** | Endpoints that returned personal or secret data in a captured response | One number per kind, such as email or phone |

To combine conditions the tiles cannot express, such as open findings and no security test, use the **Risk** menu in the filter row. See [Filtering](https://qodex.ai/docs/api-testing-endpoint-catalog.md#filtering) for every filter.

## How endpoints enter the catalog

Endpoints arrive from three places:

1. **Spec import**: every HTTP operation in an OpenAPI or Swagger document, plus every request in a Postman collection. Spec-derived fields (request schema, response schema, parameters, summary) populate at import time.
2. **Auto-discovery**: the deterministic crawler walks your app and captures every API call the UI makes. New method and path pairs are added to the catalog with their observed headers, status, and body shape.
3. **Live runs**: every scenario execution syncs the endpoints it touched back to the catalog, incrementing the test count and updating last-tested timestamps.

Re-importing a spec preserves user edits. Playground-owned fields (name, headers, body, auth when edited) stay; spec-only fields (parameters, request schema, summary) refresh. Every change to an endpoint's definition is recorded in its history.

## Coverage status definitions

| Status | What it means |
| - | - |
| **Covered** | At least one scenario touches this endpoint via a non-cleanup step. |
| **Uncovered** | Zero scenarios touch this endpoint. |
| **Failing** | Covered, and the last run failed. Filter with **Risk > Last run > Failing**. |
| **Errored** | Covered, and the last run errored instead of passing or failing. Filter with **Risk > Last run > Errored**. |
| **Never run** | Covered, but no covering scenario has run yet. Filter with **Risk > Last run > Never run**. |

The "touch" rule is deliberately generous. An auth endpoint that appears as a setup step in twenty scenarios counts as covered because those flows exercise it. A stricter "primary subject only" rule made login-heavy APIs look misleadingly uncovered. The any-step rule better matches what teams mean by "this endpoint has tests."

## The fill-coverage scan mode

`fill-coverage` is a scan mode that targets endpoints with zero scenarios. The agent:

1. Looks up the uncovered endpoints.
2. Clusters the uncovered endpoints by tag or path prefix into groups of 5 to 8.
3. Spawns up to 5 parallel sub-agents (one per cluster) to author scenarios.
4. Re-queries gaps between waves to converge on full coverage.

Auth and setup endpoints are reused automatically. You do not have to carve out a skip list for login chains the agent has already learned.

To trigger a fill-coverage run:

```text theme={null}
Fill the API coverage gaps for the Users tag. Skip anything
already covered.
```

You can also click **Cover N gaps** at the top of the API governance page to start the same flow from chat.

The agent returns draft scenarios for uncovered endpoints, ready for review.

## When governance matters

* Use it for quarterly QA review: what is covered, what is not, and what changed.
* Use it before a release: are any critical endpoints failing?
* Use it after a spec import or a collection sync: which new or changed endpoints have zero coverage? Set **Changed** to the last 7 days and pick **Uncovered**.
* Use it for security sweeps: which auth-required endpoints have no security tests?

The view is filterable by coverage, auth, security tests, last run, findings, sensitive data, method, tag, and recent changes, so you can answer each of these in one view.

## When not to use it

* **Single-endpoint debugging.** Use the API Playground for that. The catalog is the bird's-eye view.
* **Real-time alerting.** Governance reflects state at view time. For real-time pass/fail signals, watch test-run dashboards.

## On the roadmap

> [!TIP]
>
> Route-table vs scenarios diff: once your GitHub repo is linked, the agent parses your actual route table and compares it against the spec-derived catalog. Endpoints that exist in code but are missing from the spec surface as "shadow endpoints." Endpoints in the spec that no longer exist in code surface as "dead routes." Time-series tracking of coverage percentage with a visual coverage map follows.

## Related

> [card] [Endpoint catalog](https://qodex.ai/docs/api-testing-endpoint-catalog.md)
>
> The queryable list of every endpoint.

> [card] [Scenarios](https://qodex.ai/docs/api-testing-scenarios.md)
>
> The unit being counted as coverage.

> [card] [Auth profiles](https://qodex.ai/docs/api-testing-auth-profiles.md)
>
> How role-aware coverage gets clean.

> [card] [Findings](https://qodex.ai/docs/findings.md)
>
> What surfaces when a covering scenario fails.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.