Skip to main content

​
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:
FilterWhat it does
TagScope to one module: auth, users, billing. Tags come from the spec (tags[]) or from Postman folder names.
RoleScope to endpoints scenarios cover under a specific auth profile (admin, user, viewer).
CoverageTested, untested, or failing. See API governance for definitions.
Auth statusrequired, none, or unknown (derived from spec tags and observed traffic).
FindingsEndpoints 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

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.

API governance

Coverage view over the same catalog.

API Playground

Edit and run a single row.

Import an OpenAPI spec

Populate the catalog from a spec.

Import a Postman collection

Populate the catalog from Postman.