Generate Postman Collections from OpenAPI

Every request in a Postman collection — method, URL, headers, an example body — is already fully described in an OpenAPI document, just in a different shape. Hand-building a collection from a spec someone gave you is redoing work a converter does mechanically and without typos. The useful thing to know isn't that this conversion exists — it's exactly what carries over and what doesn't, since assuming the wrong half is the fast way to ship a broken collection to a teammate.

What carries over automatically

• Folders by tag. Each operation's first tags entry becomes the Postman folder it lands in; untagged operations land in a catch-all "Other" folder rather than being dropped.
• A base URL as a collection variable, not baked into every request. The first servers[].url (OpenAPI 3.x) or the host + schemes + basePath combination (Swagger 2.0) becomes a single {{baseUrl}} collection variable that every request references — switch environments in Postman by editing it once, not by find-and-replacing across every request.
• Path parameters, converted to Postman's syntax. A template like /pets/{petId} becomes {{baseUrl}}/pets/:petId, with petId set up as a proper Postman path variable.
• Query and header parameters — names and descriptions, not values. Every declared parameter gets added to the request's Params or Headers tab with its description carried over, but the value field is left blank. This is worth knowing going in: the collection documents what a request accepts, it doesn't decide what value you'll test with.
• A generated example request body. For a request body backed by a schema, a realistic example gets built recursively: the schema's own example or default wins if present, then the first enum value, then a format-aware placeholder for strings (an actual email-shaped string for format: email, a real-looking UUID for format: uuid, an ISO date for format: date-time, and so on). allOf schemas get merged into one object; oneOf/anyOf use their first branch.

What doesn't carry over

These are the gaps worth checking for before assuming an imported collection is ready to send:

• Authentication. A spec's security requirements and securitySchemes (API key, Bearer token, OAuth2 flow) describe that an endpoint needs auth, not a value a converter can invent — expect to set up Postman's Authorization tab or a collection-level auth setting by hand after import, once per collection rather than once per request if you use collection-level inheritance.
• Cookie parameters. Postman manages cookies through its own cookie jar, separate from anything a collection file can declare — a cookie-location parameter in the spec has nowhere to land in the exported request.
• Response examples. The collection's example-response list comes back empty. If you want Postman to show a saved example response per request, that's a manual addition (or a separate mocking step) after import — the spec's own response schemas are a good source to build them from by hand.

Automating it: the CLI converter

For converting in a script or CI step instead of a browser tool, openapi-to-postmanv2 is the actively maintained converter under the postmanlabs GitHub organization:

npm install -g openapi-to-postmanv2
openapi2postmanv2 -s spec.yaml -o collection.json -p

-s is the input spec, -o the output collection file, and -p pretty-prints the result. It's also usable as a Node module (require("openapi-to-postmanv2")) if the conversion needs to happen inside a larger build script rather than as a standalone step.

Common mistakes specific to this case

• Assuming an imported collection is ready to send as-is. Auth headers and real parameter values still need filling in — the collection documents the shape of a valid request, it doesn't supply working credentials or test data.
• Converting a spec with broken $refs or malformed operations. These don't necessarily surface as a hard parse error — they just produce an incomplete request in the output, silently missing the fields that came from the broken reference. Validate first; see How to Validate OpenAPI Specifications.
• Not noticing multiple tags on one operation. Only the first tag determines the folder — an operation tagged ["Users", "Admin"] lands under Users, not duplicated into both folders.
• Re-exporting after every spec change instead of re-importing. Postman treats a fresh import as a new collection by default — if the team edits requests directly in Postman after import, regenerating and re-importing from an updated spec can silently overwrite those manual changes rather than merge with them.

Try it yourself

OpenAPI to Postman generates a Postman Collection v2.1 file from a pasted, uploaded, or example OpenAPI/Swagger document — no Postman account needed to generate it, and nothing is uploaded anywhere. Run the spec through OpenAPI Validator first if the export looks incomplete, or browse it with OpenAPI Viewer if you just need to read it rather than export it.