About

Postman Collections use a proprietary schema (v2.0 and v2.1) that encodes API requests, folder structures, authentication, and example responses into a nested JSON document. OpenAPI v3.0 is the industry-standard specification for describing RESTful APIs, consumed by code generators, documentation engines, and gateway platforms. Manual conversion between these formats is error-prone. Mismatched path parameters, lost authentication schemes, or dropped request bodies break downstream tooling and can delay integration by days. This tool parses the full Postman Collection structure - including nested folders, auth inheritance, formdata and raw body types, query parameters, headers, and saved responses - and emits a compliant OpenAPI 3.0 document. It infers JSON Schema types from example payloads and maps Postman variables ({{baseUrl}}) to OpenAPI server templates. Output is available in both JSON and YAML. The conversion runs entirely in your browser with no server round-trip. Limitation: deeply nested polymorphic response bodies are approximated as flat object schemas.

Formulas

The conversion follows a deterministic mapping algorithm. Each Postman item node is traversed recursively. Leaf nodes (requests) produce path operations. Branch nodes (folders) produce tags.

map(item) →

{

paths[url][method] if item.request ≠ NULLmap(item.item) if item.item ≠ NULL

URL normalization strips the host and protocol, converts Postman path variables from colon-prefix to brace notation:

path = replace(url, /:([a-zA-Z]+)/g, /{$1})

Schema inference from a JSON example body follows type detection rules:

inferType(value) →

{

string if typeof value = "string"number if typeof value = "number"integer if Number.isInteger(value)boolean if typeof value = "boolean"array if Array.isArray(value)object if typeof value = "object"

Where value = the parsed JSON value from the request or response body example. Each object type recursively generates properties with nested inferType calls. Each array type infers items schema from the first element.

Reference Data

Postman Feature	OpenAPI 3.0 Mapping	Notes
Collection info.name	info.title	Direct mapping
Collection info.description	info.description	Markdown preserved
Folders (nested item)	tags	Folder name becomes tag
Request method	HTTP verb (get, post, etc.)	Lowercased
Request url.raw	paths key	Variables resolved to {param}
URL :pathParam	parameters with in: path	Colon syntax converted
Query parameters	parameters with in: query	Disabled params skipped by default
Headers	parameters with in: header	Content-Type excluded (implicit)
body.mode: raw (JSON)	requestBody with application/json	Schema inferred from example
body.mode: formdata	requestBody with multipart/form-data	File types detected
body.mode: urlencoded	requestBody with application/x-www-form-urlencoded	Key-value pairs mapped
body.mode: raw (XML)	requestBody with application/xml	Schema as string type
body.mode: raw (text)	requestBody with text/plain	No schema inference
Saved responses	responses with status codes	Body parsed for schema & examples
auth.type: bearer	securitySchemes.bearerAuth	HTTP bearer scheme
auth.type: basic	securitySchemes.basicAuth	HTTP basic scheme
auth.type: apikey	securitySchemes.ApiKeyAuth	Header or query location
auth.type: oauth2	securitySchemes.oauth2	Flows mapped where possible
Collection variables	Server variables	{{var}} → {var}
url.host + url.protocol	servers[0].url	Combined into server URL
Request name	summary	Used as operation summary
Request description	description	Markdown preserved
Postman v2.0 schema	OpenAPI 3.0.3	Auto-detected, normalized first
Postman v2.1 schema	OpenAPI 3.0.3	Primary target format

Frequently Asked Questions

Each top-level folder in the Postman Collection becomes an OpenAPI tag. Requests inside nested sub-folders inherit the top-level folder name as their tag. The folder hierarchy is flattened because OpenAPI 3.0 does not support nested tag grouping. Folder descriptions are mapped to tag descriptions in the output.

Postman variables in double-brace notation ({{variable}}) in the URL host are converted to OpenAPI server URL templates with single-brace notation ({variable}). Collection-level variables with default values are mapped to server variable objects. Variables in path segments are converted to path parameters. Variables in query values remain as-is since OpenAPI does not support templated query values - a comment is added to the parameter description.

Both v2.0 and v2.1 schemas are supported. The converter auto-detects the version by checking the info.schema field. v2.0 collections have a slightly different URL structure (string vs. object), and the converter normalizes v2.0 URLs into the v2.1 object format before processing. The output OpenAPI version is always 3.0.3.

The inference engine detects string, number, integer, boolean, object, and array types from a single example. For arrays, it infers the items schema from the first element. For objects, it recursively generates properties. Limitations: it cannot detect nullable fields, enums, or union types from a single example. If no example body exists, the schema defaults to type object with no properties. For production use, treat the inferred schema as a starting point and refine manually.

By default, disabled query parameters (those with disabled: true in Postman) are excluded from the OpenAPI output. There is an option in the converter settings to include them. When included, they are marked with x-disabled: true as a vendor extension. Disabled headers follow the same behavior.

Postman supports auth at collection, folder, and request levels with an inheritance model. The converter resolves the effective auth for each request by walking up the hierarchy. If a request has auth type "inherit", it uses the parent folder's auth, which may in turn inherit from the collection. The resolved auth is mapped to OpenAPI securitySchemes (bearer, basic, apikey, oauth2) and applied per-operation via the security array. Collection-level auth becomes the global security requirement.

Yes. The output conforms to the OpenAPI 3.0.3 specification and passes validation against the official JSON Schema. It can be loaded into Swagger UI, Redoc, Stoplight, or fed into code generators like openapi-generator-cli. However, inferred schemas may need refinement for strict generators that require all properties to be explicitly typed. Test the output with an OpenAPI validator before feeding it into production pipelines.