Full catalog in one request

GET /v1/catalog returns every visible vendor with fully detailed providers — no N+1 walk.

A consumer that wants everything — a form builder, a provider picker, an exported snapshot — used to walk the catalog N+1 style: list vendors, then fetch every provider one by one for its schemas. GET /v1/catalog replaces that with one request:

curl -s "$CREDS_BASE/v1/catalog" -H "Authorization: Bearer $TOKEN"

{
  "vendors": [
    {
      "code": "deepl",
      "name": "DeepL",
      "website": "https://www.deepl.com",
      "status": "active",
      "lifecycle": null,
      "providers": [
        {
          "code": "deepl_api",
          "name": "DeepL API",
          "category": "mt",
          "status": "active",
          "credential_resolution": {"...": "..."},
          "credential_schema": {"...": "..."},
          "configuration_schema": {"...": "..."},
          "capabilities": {"...": "..."},
          "technical_info": {"...": "..."},
          "lifecycle": null
        }
      ]
    }
  ],
  "catalog_version": "2026.08.24"
}

Each provider node carries all its catalog data — the same fields as the provider detail, minus the redundant vendor nesting.

Three properties to rely on:

• Nothing about stored credentials. Not even whether any exist. The response is pure catalog; for "is anything configured?" use Credential Status.
• Visibility is the usual matrix. Regular roles get active/deprecated vendors and providers; provider_admin/auditor also disabled; include_removed=true (admin/auditor only, otherwise 403) adds removed on both levels. See Vendors and Providers.
• No pagination. The payload is bounded by the size of the YAML catalog the service already holds in memory. Cache it keyed by catalog_version if you call it often — it only changes with a deployment.