Export OpenAPI to a Postman collection

Turn an OpenAPI spec into an importable Postman collection — each path becomes a request, grouped into folders, with the base URL as a variable — so the team can start testing without rebuilding requests by hand.

Open this example in OpenAPI to Postman

Open the tool, then paste the sample input below. Everything runs locally in your browser.

Open this example in OpenAPI to Postman →

The problem

Recreating every endpoint in Postman by hand is slow and drifts from the spec. Exporting the OpenAPI spec to a Postman collection gives you all the requests, grouped and parameterized, in one import — and it stays consistent with the contract.

Sample input

OpenAPI (excerpt)
servers: [ { url: https://api.example.com } ]
paths:
  /orders: { get: { summary: List orders } }

Expected output

Postman collection (excerpt)
{
  "info": { "name": "Example API" },
  "variable": [ { "key": "baseUrl", "value": "https://api.example.com" } ],
  "item": [ { "name": "List orders",
              "request": { "method": "GET", "url": "{{baseUrl}}/orders" } } ]
}

The server URL becomes a {{baseUrl}} collection variable and each operation becomes a named request, so switching environments only changes the variable.

How to do it

  1. Paste the OpenAPI spec.
  2. Convert it to a Postman collection.
  3. Check the folders, requests, and the base-URL variable.
  4. Download the collection JSON.
  5. Import it into Postman.

Common mistakes

  • Hard-coding the base URL instead of using a collection variable.
  • Losing auth settings that are not expressed in the spec.
  • Expecting example response bodies the spec does not define.
  • Importing into the wrong workspace.
  • Not re-exporting after the spec changes, so the collection drifts.

Related tools

Related guides

FAQ

How do I turn an OpenAPI spec into a Postman collection?

Paste the spec and export it. Each path becomes a request grouped into folders, and the server URL becomes a collection variable you can import into Postman.

Does the base URL become a variable?

Yes. The server URL is stored as a collection variable such as {{baseUrl}}, so switching environments only means changing one value.

Is authentication included?

Auth that the spec describes is mapped where possible, but credentials and schemes not expressed in the spec must be set in Postman after import.

Will example responses be included?

Only if the spec defines example bodies. Otherwise the collection contains the requests without saved example responses.

Is my spec uploaded?

No. The conversion runs locally in your browser. Your spec is not sent to a server.

The Postman collection is built locally in your browser. Your spec is not uploaded.

Explore more JSON and API contract tools

Export to Postman, generate clients, validate schemas and query payloads — grouped in one place.

View the JSON & API contract toolkit →

Practical example and expected result

Turn an OpenAPI spec into an importable Postman collection - each path becomes a request, grouped into folders, with the base URL as a variable - so the team can start testing without rebuilding requests by hand. In practice, this is most useful when you need a quick, repeatable check on a OpenAPI spec before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is servers: [ { url: https://api.example.com } ] paths: /orders: { get: { summary: List orders } }. The expected result should resemble { "info": { "name": "Example API" }, "variable": [ { "key": "baseUrl", "value": "https://api.example.com" } ], "item": [ { "name": "List ord..., with the same important values preserved.

Troubleshooting checklist

  • Confirm you copied the complete OpenAPI spec and not only a partial line or truncated preview.
  • Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
  • Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
  • Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps