OpenAPI → Postman Collection Converter
Converts OpenAPI 3.x or Swagger 2.0 specs into a valid Postman Collection v2.1.
Step 1 — Detect & Validate Input
Identify the spec version from the input:
openapi: 3.x.x→ OpenAPI 3swagger: "2.0"→ Swagger 2
If the input is truncated or partial, convert what's available and note missing sections.
Step 2 — Extraction Mapping
OpenAPI 3 → Postman
| OpenAPI field | Postman mapping |
|---|---|
info.title | Collection name |
info.description | Collection description |
servers[0].url | {{base_url}} variable |
paths.<path>.<method> | One request item per operation |
operationId or summary | Request name |
parameters (path/query/header) | URL path variables, query params, headers |
requestBody.content.application/json.schema | Body (raw JSON), generate example from schema |
responses | Saved example responses |
components.securitySchemes | Collection-level auth |
tags | Folder grouping |
Swagger 2 → Postman
| Swagger field | Postman mapping |
|---|---|
host + basePath | {{base_url}} |
paths.<path>.<method> | Request item |
parameters | Query/path/header/body params |
consumes / produces | Content-Type / Accept headers |
securityDefinitions | Collection auth |
tags | Folders |
Step 3 — Generate Example Bodies
For each request with a requestBody or body parameter, generate a realistic example JSON body from the schema:
- Use property names as keys
- Infer sensible example values from type + format (e.g.,
"email"format →"[email protected]","date-time"→"2024-01-15T10:30:00Z") - For
$refschemas, resolve them inline
Step 4 — Auth Handling
Map security schemes to Postman auth:
| OpenAPI scheme | Postman auth type |
|---|---|
http: bearer | bearer with {{token}} |
http: basic | basic with {{username}} / {{password}} |
apiKey: header | apikey header with {{api_key}} |
apiKey: query | apikey query param |
oauth2 | oauth2 (note: requires manual token setup) |
Apply auth at collection level if all endpoints share the same scheme. Override at request level for exceptions.
Step 5 — Build Collection JSON
Use the standard v2.1 structure (same schema as postman-collection-generator skill).
Key differences for spec-converted collections:
- Always group by
tagsinto folders - Include
descriptionfield on each request fromoperationId+summary+description - Add saved example responses where
responsesare defined in the spec
"response": [
{
"name": "200 OK",
"status": "OK",
"code": 200,
"header": [{ "key": "Content-Type", "value": "application/json" }],
"body": "{ \"id\": 1, \"name\": \"example\" }",
"originalRequest": { <copy of the request> }
}
]
Step 6 — Environment File
Extract all variables into a companion environment:
base_urlfromservers[0].urlorhost + basePathtoken,api_key,username,passwordas empty placeholders- Any server variables from
servers[0].variables
Step 7 — Output
collection.json— Full Postman Collection v2.1environment.json— Matching environment file- Conversion summary: number of endpoints converted, folders created, auth type detected, any fields skipped or approximated
- Import instructions
Edge Cases
$refchains: Resolve all$refpointers inline before mappingallOf/oneOf/anyOf: Use the first/primary schema for body generation; note alternatives in description- Path parameters: Convert
{param}to:paramin URL path AND add tovariablearray in url object - Multiple content types: Prefer
application/json; note others in request description - No operationId: Generate name from
METHOD /path(e.g.,GET /users/{id}→Get User by ID)
Quality Checklist
- Every
pathsentry produces at least one request - Path params use
:paramformat in Postman URL - All
$refresolved — no raw$refstrings in output - Auth tokens are
{{variables}}, never hardcoded - JSON output is valid and importable
After Completing the API Design
Once the API design output is delivered, ask the user:
"Would you like me to generate API documentation for this design? (yes/no)"
If the user says yes:
- Check if the API Documentation skill is available in the installed skills list
- If the skill is available:
- Read and follow the instructions in the API Documentation skill
- Use the API design output above as the input
- If the skill is NOT available:
- Inform the user: "It looks like the API Documentation skill isn't installed. You can install it and re-run.
If the user says no:
- End the task here