This tool reads an OpenAPI 3.x spec (YAML or JSON) and generates a Postman Collection v2.1 JSON file — one Postman request per operation, with path/query/header parameters and a sample request body pre-filled, ready to import into Postman without hand-building each request.

How it works

The input is parsed as JSON first, falling back to YAML via js-yaml if that fails. For every path and HTTP method in spec.paths, curly-brace path parameters like {id} are rewritten to Postman's colon syntax (:id). Parameters with in: header or in: query become Postman header/query entries, using each parameter's example (or schema.example) as the value. If the operation has an application/json request body, its schema is walked recursively to synthesize a sample JSON payload — objects and arrays recurse into their properties/items, and each leaf falls back to a type-appropriate placeholder (0 for integer/number, true for boolean, "string" otherwise) when no example is present.

Features

Accepts both YAML and JSON OpenAPI input
Converts {id} path parameters to Postman's :id syntax automatically
Generates a sample JSON body from each schema, using declared examples where available
Uses {{baseUrl}} as a Postman environment variable instead of a hardcoded host
Copy, download as postman_collection.json, or load a spec file directly

Example

Input (OpenAPI YAML, abbreviated): a POST /users operation with a JSON body schema of { name: string (example: Alice), email: string (example: alice@example.com) }.

Output (Postman item, abbreviated):

{
  "name": "Create user",
  "request": {
    "method": "POST",
    "header": [{ "key": "Content-Type", "value": "application/json" }],
    "body": {
      "mode": "raw",
      "raw": "{\n  \"name\": \"Alice\",\n  \"email\": \"alice@example.com\"\n}"
    },
    "url": { "raw": "{{baseUrl}}/users", "host": ["{{baseUrl}}"], "path": ["users"], "query": [] }
  }
}

Common errors

"Not an OpenAPI spec — expected a top-level paths object" means the input parsed as valid JSON/YAML but doesn't look like an OpenAPI document. This tool only reads paths, info.title, and each operation's parameters/requestBody — other OpenAPI features like components.$ref references, security schemes, and server variables aren't resolved, so a heavily $ref-based spec may produce sparser requests than expected.

Best practices

Add concrete example values to your OpenAPI parameters and schemas before converting — they flow straight into the generated Postman request, saving you from editing placeholder values by hand. After importing, create a Postman environment with a baseUrl variable matching your spec's actual server URL.

Frequently Asked Questions

Does this accept YAML or JSON specs?▾

Both — most OpenAPI specs in the wild are written as YAML, so the input is parsed as JSON first and falls back to YAML if that fails, meaning you can paste either format directly.

How are OpenAPI path parameters ({id}) converted?▾

To Postman's :id colon-prefix path variable syntax inside the URL, matching how Postman itself represents path variables in a request.

Where does the request body come from?▾

Generated from the operation's requestBody.content['application/json'].schema — each property's example value is used if present, otherwise a placeholder (0, true, "string") based on its declared type, so you get a valid, editable JSON body ready to send.

Does the output include a base URL?▾

Requests use {{baseUrl}} as a Postman environment variable placeholder rather than a hardcoded host, since OpenAPI's servers list and Postman's environment variables serve the same purpose differently — set {{baseUrl}} in a Postman environment after importing.