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

If you’ve been using API Catalog to monitor your services or Postman Spec Hub to manage your API specifications, you’ve probably wished you could pull that data into your own tooling. With the 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 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 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 is where you design, standardize, and govern your API specifications. It supports OpenAPI (2.0, 3.0, and 3.1), AsyncAPI 2.0, protobuf (versions 2 and 3), and GraphQL.

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:

- 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 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 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
• About the API Catalog
• Explore your services in API Catalog
• Design API specifications in Spec Hub
• The Postman CLI documentation
• OpenAPI 3.1 specification
• API Catalog product page
• Spec Hub product page