Swagger to Postman Collection

Convert an OpenAPI 3.x or Swagger 2.0 spec into a Postman collection you can import directly. Every operation becomes a request with the right method, URL, path and query parameters, headers, and a sample JSON body generated from the schema. Operations are grouped into folders by tag, and the server URL is wired to a {{baseUrl}} variable. The result is standard Postman Collection v2.1 JSON — paste your spec, copy the output, and import.

collection.postman_collection.json

In Postman: Import → Raw text, paste, and import. Then set the baseUrl collection variable if you use multiple environments.

How to use the Swagger to Postman Collection

Paste your spec or load a file, then copy the generated JSON and import it into Postman with Import → Raw text. Each path-and-method pair becomes one request, named from the operation's summary or operationId. Path parameters such as {petId} are converted to Postman's :petId form and listed as URL variables; query parameters are added to the request URL; and header parameters become request headers.

When an operation declares a JSON request body, the tool builds a sample payload from the schema — using any example or default values it finds, falling back to type-appropriate placeholders — so you have a body to edit rather than a blank one. Choose whether to group requests into folders by their first tag (tidy for large APIs) or keep a flat list. The base server URL is stored in a {{baseUrl}} variable so you can repoint the whole collection at staging or production in one place.

Why convert a spec to a Postman collection

An OpenAPI or Swagger spec is the machine-readable contract for an API; a Postman collection is an executable set of saved requests. Converting between them lets you go from documentation to hands-on testing in seconds, without manually re-creating each endpoint. This is the everyday version of what Postman's own importer does — turning paths, parameters, and requestBody definitions into ready-to-send requests.

The conversion preserves the structure that matters for testing. The collection's info block carries the API title and description; each request's url is split into host, path segments, query, and path variables so Postman's URL editor understands it; and headers include declared header parameters plus a Content-Type when there's a body. Grouping by tag mirrors how most specs already organise operations, producing a folder per resource. The Collection v2.1 schema reference in the output is what tells Postman — and other compatible tools like Insomnia or Hoppscotch via their importers — how to read the file.

Generating a body from the schema is the part that saves the most time. Rather than importing empty requests, you get a realistic JSON payload seeded from the spec's examples and types, so a POST or PUT is one edit away from working. The collection is a starting point: you'll still add real auth tokens, environment variables, and test scripts, but the tedious scaffolding — every URL, every parameter, every sample body — is done.

Common use cases

  • Spin up API testing. Import an unfamiliar API and start sending real requests immediately.
  • QA handoff. Give testers a ready collection instead of a raw spec file to decipher.
  • Smoke-test a new build. Generate requests for every endpoint to verify a deployment quickly.
  • Demo and exploration. Turn a published OpenAPI doc into a clickable collection for a walkthrough.

Frequently asked questions

Which Postman collection format does it produce?
Collection Schema v2.1, the current import format. The output includes the official schema URL in its info block, so Postman, Insomnia, and Hoppscotch importers all recognise it.

Does it handle both OpenAPI 3 and Swagger 2?
Yes. It reads servers (OpenAPI 3) or host/basePath/schemes (Swagger 2) for the base URL, and supports both the requestBody style (OAS3) and in: body parameters (Swagger 2) when building request payloads.

How are request bodies generated?
From the JSON schema of the request body: it uses any example or default values present, picks the first enum value, and otherwise inserts type-appropriate placeholders. The result is an editable sample, not a validated payload — adjust values before sending.

What about authentication?
Security schemes are not converted into Postman auth automatically, because tokens and credentials should never be embedded. Add your auth in Postman at the collection or request level after importing — a one-time setup that then applies everywhere.

Are my spec and any keys uploaded?
No. The entire conversion runs in your browser. Nothing is sent to a server, so internal specs stay on your machine — and because auth is left out, no secrets end up in the generated file.