# New in the Postman API v1.39: API Catalog and Spec Hub endpoints

If you've been using [API Catalog](https://learning.postman.com/docs/api-catalog/overview) to monitor your services or [Postman Spec Hub](https://learning.postman.com/docs/design-apis/specifications/overview) to manage your API specifications, you've probably wished you could pull that data into your own tooling. With the [Postman API](https://www.postman.com/postman/postman-public-workspace/documentation/i2uqzpp/postman-api) collection v1.39.0, now you can. This release adds 8 new endpoints across 2 feature areas: API Catalog services and Spec Hub version tags. I'll walk through what each one does, show you the requests, and share a few patterns I've found useful for putting them to work.

## What's in the release

 Here's the full list of new endpoints: ### API Catalog

 | Method | Endpoint | What it returns |
|---|---|---|
| GET | `/api-catalog/services` | List of services in a system environment with analytics, compliance, and governance metadata |
| GET | `/api-catalog/services/{serviceId}` | Details for a single service, including health, traffic, compliance, ownership, and dependencies |
| GET | `/api-catalog/services/{serviceId}/endpoints` | Observed API endpoints for a service with performance metrics |
| GET | `/api-catalog/services/{serviceId}/monitor-runs` | Scheduled [monitor](https://learning.postman.com/docs/monitoring-your-api/monitor-overview/) runs with summary statistics |
| GET | `/api-catalog/services/{serviceId}/spec-lints` | API specification lint runs with summary statistics and per-severity issue counts |
| GET | `/api-catalog/services/{serviceId}/ci-runs` | CI collection runs with summary statistics, pipeline details, and Git metadata |

### Spec Hub

 | Method | Endpoint | What it returns |
|---|---|---|
| GET | `/specs/{specId}/version-tags` | List of a specification's version tags |
| GET | `/specs/{specId}/version-tags/{tagId}/files` | Snapshot of a specification at the tagged point in time |
| POST | `/specs/{specId}/version-tags` | Creates a new version tag for a specification |

## API Catalog: query your services programmatically

 API Catalog gives you a [centralized view](https://www.postman.com/product/api-catalog/) of every service in your organization. It aggregates traffic analytics, compliance signals from monitor runs and CI pipelines, specification lint results, and governance metadata into a single dashboard. The new endpoints open all of that data up to automation. ### List your services

 Start by pulling the full list of services in your system environment: ```
GET {{baseUrl}}/api-catalog/services
X-API-Key: {{postman-api-key}}

```

 The response includes each service's analytics, compliance status, and governance metadata: ```
{
  "services": [
    {
      "id": "svc_a1b2c3",
      "name": "payments-api",
      "workspace": {
        "id": "ws_d4e5f6",
        "name": "Payments Team"
      },
      "analytics": {
        "totalEndpoints": 24,
        "requestVolume7d": 1482300,
        "p95Latency": 142
      },
      "compliance": {
        "monitorStatus": "passing",
        "ciStatus": "passing",
        "specLintScore": 94
      },
      "governance": {
        "governanceGroup": "public-apis",
        "specVersion": "OpenAPI 3.1"
      }
    }
  ]
}

```

### Drill into a service

 Once you have a service ID, you can pull the full picture, including health, traffic, ownership, and dependency data: ```
GET {{baseUrl}}/api-catalog/services/svc_a1b2c3
X-API-Key: {{postman-api-key}}

```

 ```
{
  "id": "svc_a1b2c3",
  "name": "payments-api",
  "health": {
    "status": "healthy",
    "uptimePercent": 99.97,
    "errorRate4xx": 0.3,
    "errorRate5xx": 0.01
  },
  "traffic": {
    "requestVolume24h": 211758,
    "p50Latency": 45,
    "p95Latency": 142,
    "p99Latency": 310
  },
  "ownership": {
    "team": "Payments Team",
    "workspace": "ws_d4e5f6"
  },
  "dependencies": [
    { "serviceId": "svc_x7y8z9", "name": "auth-service" },
    { "serviceId": "svc_m1n2o3", "name": "notifications-api" }
  ]
}

```

 This is the kind of data I'd want feeding into a weekly API health report or a Slack alert when error rates spike. ### Check endpoint performance

 The `/endpoints` subresource returns the observed API endpoints for a service along with their performance metrics: ```
GET {{baseUrl}}/api-catalog/services/svc_a1b2c3/endpoints
X-API-Key: {{postman-api-key}}

```

 ```
{
  "endpoints": [
    {
      "method": "POST",
      "path": "/v1/payments",
      "requestVolume7d": 342100,
      "p95Latency": 189,
      "errorRate": 0.02
    },
    {
      "method": "GET",
      "path": "/v1/payments/{paymentId}",
      "requestVolume7d": 890400,
      "p95Latency": 67,
      "errorRate": 0.001
    }
  ]
}

```

### Pull compliance signals

 The compliance-related endpoints give you granular access to monitor runs, specification lint results, and CI pipeline data. Here's how to check recent specification lint runs: ```
GET {{baseUrl}}/api-catalog/services/svc_a1b2c3/spec-lints
X-API-Key: {{postman-api-key}}

```

 ```
{
  "specLints": [
    {
      "id": "lint_r4s5t6",
      "runAt": "2026-05-03T14:22:00Z",
      "status": "completed",
      "summary": {
        "totalIssues": 3,
        "errors": 0,
        "warnings": 2,
        "info": 1
      }
    }
  ]
}

```

 And CI collection runs, which include pipeline details and Git metadata: ```
GET {{baseUrl}}/api-catalog/services/svc_a1b2c3/ci-runs
X-API-Key: {{postman-api-key}}

```

 ```
{
  "ciRuns": [
    {
      "id": "ci_u7v8w9",
      "runAt": "2026-05-03T15:30:00Z",
      "status": "passed",
      "summary": {
        "totalTests": 48,
        "passed": 48,
        "failed": 0
      },
      "pipeline": {
        "provider": "github-actions",
        "workflow": "api-tests.yml"
      },
      "git": {
        "branch": "main",
        "commitSha": "a1b2c3d"
      }
    }
  ]
}

```

## Spec Hub: manage version tags through the API

 [Spec Hub](https://www.postman.com/product/spec-hub/) is where you design, standardize, and govern your API specifications. It supports [OpenAPI](https://spec.openapis.org/oas/v3.1.0) (2.0, 3.0, and 3.1), [AsyncAPI](https://www.asyncapi.com/docs/reference/specification/v2.6.0) 2.0, [protobuf](https://protobuf.dev/programming-guides/proto3/) (versions 2 and 3), and [GraphQL](https://spec.graphql.org/). Version tags are snapshots of a specification at a point in time. Think of them like Git tags for your API design. They let you track how your specifications evolve, compare changes between releases, and pin integrations to a known-good version. ### List version tags

 Pull the tags for a specification to see its version history: ```
GET {{baseUrl}}/specs/spec_j1k2l3/version-tags
X-API-Key: {{postman-api-key}}

```

 ```
{
  "versionTags": [
    {
      "id": "tag_p4q5r6",
      "name": "v2.1.0",
      "createdAt": "2026-04-28T10:00:00Z",
      "createdBy": "usr_abc123"
    },
    {
      "id": "tag_s7t8u9",
      "name": "v2.0.0",
      "createdAt": "2026-03-15T09:30:00Z",
      "createdBy": "usr_abc123"
    }
  ]
}

```

### Get a version tag snapshot

 Retrieve the files for a specific version tag to see the specification as it existed at that point: ```
GET {{baseUrl}}/specs/spec_j1k2l3/version-tags/tag_p4q5r6/files
X-API-Key: {{postman-api-key}}

```

 ```
{
  "tag": {
    "id": "tag_p4q5r6",
    "name": "v2.1.0",
    "createdAt": "2026-04-28T10:00:00Z"
  },
  "files": [
    {
      "path": "openapi.yaml",
      "content": "openapi: 3.1.0\ninfo:\n  title: Payments API\n  version: 2.1.0\npaths:\n  /v1/payments:\n    post:\n      summary: Create a payment\n..."
    },
    {
      "path": "components/schemas/Payment.yaml",
      "content": "type: object\nproperties:\n  id:\n    type: string\n  amount:\n    type: number\n..."
    }
  ]
}

```

 This is useful for diffing specification versions in your own tooling or for building automation that validates whether a deployed API matches its tagged specification. ### Create a version tag

 Tag a specification to freeze its current state: ```
POST {{baseUrl}}/specs/spec_j1k2l3/version-tags
X-API-Key: {{postman-api-key}}
Content-Type: application/json

{
  "name": "v2.2.0"
}

```

 ```
{
  "id": "tag_v1w2x3",
  "name": "v2.2.0",
  "createdAt": "2026-05-04T12:00:00Z",
  "createdBy": "usr_abc123"
}

```

 I've started tagging specifications as part of my release process. The tag goes out right before we merge to main so there's always a snapshot tied to what went to production. ## Patterns I've found useful

### Build an API health dashboard

 Combine the services list with the endpoints and compliance data to build a dashboard that shows your team what matters: ```
const apiKey = pm.environment.get("postman-api-key");
const baseUrl = pm.environment.get("baseUrl");

const servicesResponse = await pm.sendRequest({
    url: `${baseUrl}/api-catalog/services`,
    method: "GET",
    header: { "X-API-Key": apiKey }
});

const services = servicesResponse.json().services;

for (const service of services) {
    const endpointsResponse = await pm.sendRequest({
        url: `${baseUrl}/api-catalog/services/${service.id}/endpoints`,
        method: "GET",
        header: { "X-API-Key": apiKey }
    });

    const slowEndpoints = endpointsResponse.json().endpoints
        .filter(ep => ep.p95Latency > 200);

    if (slowEndpoints.length > 0) {
        console.log(`${service.name}: ${slowEndpoints.length} endpoints above 200ms p95`);
    }
}

```

### Automate specification tagging in CI/CD

 Add specification tagging to your release pipeline so every deployment has a corresponding version snapshot. Here's a GitHub Actions step using [the Postman CLI](https://learning.postman.com/docs/postman-cli/postman-cli-overview/): ```
- name: Tag API specification
  run: |
    curl -s -X POST \
      "https://api.postman.com/specs/${{ secrets.SPEC_ID }}/version-tags" \
      -H "X-API-Key: ${{ secrets.POSTMAN_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d '{"name": "v${{ github.ref_name }}"}'
  env:
    POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}

```

### Monitor specification compliance across services

 Pull lint results for all your services and flag anything with errors: ```
const services = servicesResponse.json().services;

for (const service of services) {
    const lintsResponse = await pm.sendRequest({
        url: `${baseUrl}/api-catalog/services/${service.id}/spec-lints`,
        method: "GET",
        header: { "X-API-Key": apiKey }
    });

    const latestLint = lintsResponse.json().specLints[0];
    if (latestLint && latestLint.summary.errors > 0) {
        console.log(
            `${service.name}: ${latestLint.summary.errors} spec lint errors`
        );
    }
}

```

## Things to watch for

 **Rate limits still apply.** If you're iterating over dozens of services and calling multiple sub-endpoints per service, you'll want to add some pacing. I batch my requests in groups of 5 with a short delay between batches. **Service IDs are environment-scoped.** The same service can have different IDs across system environments. Make sure you're querying the right environment when building cross-environment comparisons. **Version tags are immutable.** Once you create a tag, you can't change it. If you need to correct something, create a new tag with an updated name. This is by design since immutability is what makes tags trustworthy as release markers. ## What this means for your workflow

 These endpoints close the gap between what you can see in Postman's dashboard and what you can automate. If you've been manually checking API Catalog for compliance status or hand-tagging specifications before releases, you can now script those workflows. The API Catalog endpoints are particularly valuable for platform engineering teams building internal developer portals. Instead of asking developers to check Postman for service health, you can surface that data wherever your team already works. The Spec Hub version tag endpoints fit naturally into [API-first](https://www.postman.com/api-first/) development workflows. Tag your specifications at every release, compare them programmatically, and catch breaking changes before they reach production. Import the updated [Postman API collection](https://www.postman.com/postman/postman-public-workspace/documentation/i2uqzpp/postman-api) into your workspace and try the new endpoints against your own services. Start with `GET /api-catalog/services` to see what data is available, then build from there. ## Resources

- [Postman API documentation](https://www.postman.com/postman/postman-public-workspace/documentation/i2uqzpp/postman-api)
- [About the API Catalog](https://learning.postman.com/docs/api-catalog/overview)
- [Explore your services in API Catalog](https://learning.postman.com/docs/api-catalog/explore)
- [Design API specifications in Spec Hub](https://learning.postman.com/docs/design-apis/specifications/overview)
- [The Postman CLI documentation](https://learning.postman.com/docs/postman-cli/postman-cli-overview/)
- [OpenAPI 3.1 specification](https://spec.openapis.org/oas/v3.1.0)
- [API Catalog product page](https://www.postman.com/product/api-catalog/)
- [Spec Hub product page](https://www.postman.com/product/spec-hub/)