Postman to OpenAPI Converter

Convert Postman collection JSON files to OpenAPI 3.x specification format with full mapping.

  • Developer & Code
  • Runs in your browser
  • Free, no signup

The guide

Tested tool guide Tested browser tools Checked August 16, 2026

What Postman to OpenAPI Converter does, with a checked example

This tool reads a Postman collection JSON file, the export you download from the Postman app, and rewrites it as an OpenAPI 3.x document. Each request in the collection becomes a path operation: method, URL path, query parameters, headers, and request body are mapped onto OpenAPI structures, and Postman's colon-style path variables (:id) become OpenAPI brace-style path parameters ({id}). The surprise is that the output is a skeleton, not a finished contract: Postman collections usually store no response data, so every operation receives a generic 200 response, and schemas are inferred from single example bodies.

Worked example

A concrete input and expected output from the current implementation.

Input

{
  "info": {
    "name": "Pets API",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": [
    {
      "name": "Get pet by id",
      "request": {
        "method": "GET",
        "url": {
          "raw": "https://api.example.com/pets/:petId?verbose=true",
          "path": ["pets", ":petId"],
          "query": [{ "key": "verbose", "value": "true" }],
          "variable": [{ "key": "petId", "value": "1" }]
        }
      }
    }
  ]
}

Expected output

{
  "openapi": "3.0.3",
  "info": {
    "title": "Pets API",
    "version": "1.0.0"
  },
  "paths": {
    "/pets/{petId}": {
      "get": {
        "parameters": [
          { "name": "petId", "in": "path", "required": true, "schema": { "type": "string" } },
          { "name": "verbose", "in": "query", "schema": { "type": "string" } }
        ],
        "responses": {
          "200": { "description": "Successful response" }
        }
      }
    }
  }
}

The collection name becomes info.title, the request method picks the get verb, and the :petId path segment is rewritten as the {petId} path parameter, which is required by OpenAPI. Path and query values map to string schemas because Postman does not type variables, and version 1.0.0 plus a generic 200 response are defaults, since the collection carries no version or response data.

How the result is produced

1

Request tree to paths

Every entry in the collection's item array becomes one operation. The request method selects the verb, and the URL's path segments, with :name segments rewritten as {name}, form the path key. Query entries and headers become parameters with in: query or in: header. Requests nested in folders are flattened; the path always comes from the request's URL, never from the folder structure.

2

Filling what Postman leaves out

OpenAPI requires an info.version and at least one response per operation, so the tool supplies defaults: version 1.0.0 and a 200 response with the description 'Successful response', unless the collection has saved examples carrying real status codes. A raw JSON request body is parsed and converted to a schema inferred from that single example; formdata and urlencoded bodies map to their media types.

Good uses

  • Migrating a team off Postman into a spec-first workflow, where the generated file is imported into Swagger UI, Redocly, or Stoplight and edited from there.
  • Turning a collection that is the only documentation of an API into an OpenAPI file for rendering reference docs or generating client stubs with OpenAPI Generator.
  • Auditing a legacy collection structurally: how many endpoints, which verbs, and which parameters exist, before hand-writing the real contract.

Limits and checks

  • Responses are placeholders. OpenAPI requires one, Postman rarely stores one, so expect a synthetic 200 and no response schemas; a specific status code appears only where the collection saved an example for it.
  • Postman variables like {{baseUrl}} and {{token}} are environment references with no OpenAPI equivalent. They survive as literal {{...}} strings in paths and headers; no servers object and no security scheme are generated from them.
  • Schemas are inferred from one example, so types and required flags reflect that single sample, and an empty body produces no requestBody. Two requests to the same path with different query strings collapse into one operation.

Common questions

Will the response schemas from my collection appear in the output?

Usually not. Collections store request definitions; response bodies exist only if you saved examples for a request. Without them the tool emits a generic 200 response with no schema, and you must write response schemas by hand. If you need them carried over, save examples in Postman before exporting.

Why does my spec still contain {{double-brace}} placeholders?

Because those are Postman environment or global variables, runtime substitutions that have no OpenAPI counterpart. The converter cannot know their values, so they remain literal. Replace them with real values in the spec, or model them yourself as an OpenAPI server variable or a securityScheme.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.