postman-openapi-converter

Name: postman-openapi-converter
Author: LambdaTest

335stars67forks

How to install postman-openapi-converter?

lambdatest/agent-skills/postman-openapi-converter

$npx -y skills add LambdaTest/agent-skills --skill postman-openapi-converter

Installs into the current project.

Summary

Convert OpenAPI 3.x or Swagger 2.0 specs (YAML or JSON) into complete, import-ready Postman Collection v2.1 JSON files. Use this skill whenever the user provides or references an OpenAPI spec, Swagger file, openapi.yaml, swagger.json, or uses phrases like "convert my OpenAPI spec

Files · 1

View on GitHub

SKILL.md

1	# OpenAPI → Postman Collection Converter
2
3	Converts OpenAPI 3.x or Swagger 2.0 specs into a valid Postman Collection v2.1.
4
5	---
6
7	## Step 1 — Detect & Validate Input
8
9	Identify the spec version from the input:
10	- `openapi: 3.x.x` → OpenAPI 3
11	- `swagger: "2.0"` → Swagger 2
12
13	If the input is truncated or partial, convert what's available and note missing sections.
14
15	---
16
17	## Step 2 — Extraction Mapping
18
19	### OpenAPI 3 → Postman
20
21	\| OpenAPI field \| Postman mapping \|
22	\|---\|---\|
23	\| `info.title` \| Collection name \|
24	\| `info.description` \| Collection description \|
25	\| `servers[0].url` \| `{{base_url}}` variable \|
26	\| `paths.<path>.<method>` \| One request item per operation \|
27	\| `operationId` or `summary` \| Request name \|
28	\| `parameters` (path/query/header) \| URL path variables, query params, headers \|
29	\| `requestBody.content.application/json.schema` \| Body (raw JSON), generate example from schema \|
30	\| `responses` \| Saved example responses \|
31	\| `components.securitySchemes` \| Collection-level auth \|
32	\| `tags` \| Folder grouping \|
33
34	### Swagger 2 → Postman
35
36	\| Swagger field \| Postman mapping \|
37	\|---\|---\|
38	\| `host` + `basePath` \| `{{base_url}}` \|
39	\| `paths.<path>.<method>` \| Request item \|
40	\| `parameters` \| Query/path/header/body params \|
41	\| `consumes` / `produces` \| Content-Type / Accept headers \|
42	\| `securityDefinitions` \| Collection auth \|
43	\| `tags` \| Folders \|
44
45	---
46
47	## Step 3 — Generate Example Bodies
48
49	For each request with a `requestBody` or `body` parameter, generate a realistic example JSON body from the schema:
50	- Use property names as keys
51	- Infer sensible example values from type + format (e.g., `"email"` format → `"user@example.com"`, `"date-time"` → `"2024-01-15T10:30:00Z"`)
52	- For `$ref` schemas, resolve them inline
53
54	---
55
56	## Step 4 — Auth Handling
57
58	Map security schemes to Postman auth:
59
60	\| OpenAPI scheme \| Postman auth type \|
61	\|---\|---\|
62	\| `http: bearer` \| `bearer` with `{{token}}` \|
63	\| `http: basic` \| `basic` with `{{username}}` / `{{password}}` \|
64	\| `apiKey: header` \| `apikey` header with `{{api_key}}` \|
65	\| `apiKey: query` \| `apikey` query param \|
66	\| `oauth2` \| `oauth2` (note: requires manual token setup) \|
67
68	Apply auth at collection level if all endpoints share the same scheme. Override at request level for exceptions.
69
70	---
71
72	## Step 5 — Build Collection JSON
73
74	Use the standard v2.1 structure (same schema as postman-collection-generator skill).
75
76	Key differences for spec-converted collections:
77	- Always group by `tags` into folders
78	- Include `description` field on each request from `operationId` + `summary` + `description`
79	- Add saved example responses where `responses` are defined in the spec
80
81	```json
82	"response": [
83	{
84	"name": "200 OK",
85	"status": "OK",
86	"code": 200,
87	"header": [{ "key": "Content-Type", "value": "application/json" }],
88	"body": "{ \"id\": 1, \"name\": \"example\" }",
89	"originalRequest": { <copy of the request> }
90	}
91	]
92	```
93
94	---
95
96	## Step 6 — Environment File
97
98	Extract all variables into a companion environment:
99	- `base_url` from `servers[0].url` or `host + basePath`
100	- `token`, `api_key`, `username`, `password` as empty placeholders
101	- Any server variables from `servers[0].variables`
102
103	---
104
105	## Step 7 — Output
106
107	1. `collection.json` — Full Postman Collection v2.1
108	2. `environment.json` — Matching environment file
109	3. Conversion summary: number of endpoints converted, folders created, auth type detected, any fields skipped or approximated
110	4. Import instructions
111
112	---
113
114	## Edge Cases
115
116	- `$ref` chains: Resolve all `$ref` pointers inline before mapping
117	- `allOf` / `oneOf` / `anyOf`: Use the first/primary schema for body generation; note alternatives in description
118	- Path parameters: Convert `{param}` to `:param` in URL path AND add to `variable` array in url object
119	- Multiple content types: Prefer `application/json`; note others in request description
120	- No operationId: Generate name from `METHOD /path` (e.g., `GET /users/{id}` → `Get User by ID`)
121
122	---
123
124	## Quality Checklist
125
126	- [ ] Every `paths` entry produces at least one request
127	- [ ] Path params use `:param` format in Postman URL
128	- [ ] All `$ref` resolved — no raw `$ref` strings in output
129	- [ ] Auth tokens are `{{variables}}`, never har

People who liked this also viewed

6 picks

Type

postman-openapi-converter

335stars67forks

View on GitHub

How to install postman-openapi-converter?

lambdatest/agent-skills/postman-openapi-converter

$npx -y skills add LambdaTest/agent-skills --skill postman-openapi-converter

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# OpenAPI → Postman Collection Converter
2
3	Converts OpenAPI 3.x or Swagger 2.0 specs into a valid Postman Collection v2.1.
4
5	---
6
7	## Step 1 — Detect & Validate Input
8
9	Identify the spec version from the input:
10	- `openapi: 3.x.x` → OpenAPI 3
11	- `swagger: "2.0"` → Swagger 2
12
13	If the input is truncated or partial, convert what's available and note missing sections.
14
15	---
16
17	## Step 2 — Extraction Mapping
18
19	### OpenAPI 3 → Postman
20
21	\| OpenAPI field \| Postman mapping \|
22	\|---\|---\|
23	\| `info.title` \| Collection name \|
24	\| `info.description` \| Collection description \|
25	\| `servers[0].url` \| `{{base_url}}` variable \|
26	\| `paths.<path>.<method>` \| One request item per operation \|
27	\| `operationId` or `summary` \| Request name \|
28	\| `parameters` (path/query/header) \| URL path variables, query params, headers \|
29	\| `requestBody.content.application/json.schema` \| Body (raw JSON), generate example from schema \|
30	\| `responses` \| Saved example responses \|
31	\| `components.securitySchemes` \| Collection-level auth \|
32	\| `tags` \| Folder grouping \|
33
34	### Swagger 2 → Postman
35
36	\| Swagger field \| Postman mapping \|
37	\|---\|---\|
38	\| `host` + `basePath` \| `{{base_url}}` \|
39	\| `paths.<path>.<method>` \| Request item \|
40	\| `parameters` \| Query/path/header/body params \|
41	\| `consumes` / `produces` \| Content-Type / Accept headers \|
42	\| `securityDefinitions` \| Collection auth \|
43	\| `tags` \| Folders \|
44
45	---
46
47	## Step 3 — Generate Example Bodies
48
49	For each request with a `requestBody` or `body` parameter, generate a realistic example JSON body from the schema:
50	- Use property names as keys
51	- Infer sensible example values from type + format (e.g., `"email"` format → `"user@example.com"`, `"date-time"` → `"2024-01-15T10:30:00Z"`)
52	- For `$ref` schemas, resolve them inline
53
54	---
55
56	## Step 4 — Auth Handling
57
58	Map security schemes to Postman auth:
59
60	\| OpenAPI scheme \| Postman auth type \|
61	\|---\|---\|
62	\| `http: bearer` \| `bearer` with `{{token}}` \|
63	\| `http: basic` \| `basic` with `{{username}}` / `{{password}}` \|
64	\| `apiKey: header` \| `apikey` header with `{{api_key}}` \|
65	\| `apiKey: query` \| `apikey` query param \|
66	\| `oauth2` \| `oauth2` (note: requires manual token setup) \|
67
68	Apply auth at collection level if all endpoints share the same scheme. Override at request level for exceptions.
69
70	---
71
72	## Step 5 — Build Collection JSON
73
74	Use the standard v2.1 structure (same schema as postman-collection-generator skill).
75
76	Key differences for spec-converted collections:
77	- Always group by `tags` into folders
78	- Include `description` field on each request from `operationId` + `summary` + `description`
79	- Add saved example responses where `responses` are defined in the spec
80
81	```json
82	"response": [
83	{
84	"name": "200 OK",
85	"status": "OK",
86	"code": 200,
87	"header": [{ "key": "Content-Type", "value": "application/json" }],
88	"body": "{ \"id\": 1, \"name\": \"example\" }",
89	"originalRequest": { <copy of the request> }
90	}
91	]
92	```
93
94	---
95
96	## Step 6 — Environment File
97
98	Extract all variables into a companion environment:
99	- `base_url` from `servers[0].url` or `host + basePath`
100	- `token`, `api_key`, `username`, `password` as empty placeholders
101	- Any server variables from `servers[0].variables`
102
103	---
104
105	## Step 7 — Output
106
107	1. `collection.json` — Full Postman Collection v2.1
108	2. `environment.json` — Matching environment file
109	3. Conversion summary: number of endpoints converted, folders created, auth type detected, any fields skipped or approximated
110	4. Import instructions
111
112	---
113
114	## Edge Cases
115
116	- `$ref` chains: Resolve all `$ref` pointers inline before mapping
117	- `allOf` / `oneOf` / `anyOf`: Use the first/primary schema for body generation; note alternatives in description
118	- Path parameters: Convert `{param}` to `:param` in URL path AND add to `variable` array in url object
119	- Multiple content types: Prefer `application/json`; note others in request description
120	- No operationId: Generate name from `METHOD /path` (e.g., `GET /users/{id}` → `Get User by ID`)
121
122	---
123
124	## Quality Checklist
125
126	- [ ] Every `paths` entry produces at least one request
127	- [ ] Path params use `:param` format in Postman URL
128	- [ ] All `$ref` resolved — no raw `$ref` strings in output
129	- [ ] Auth tokens are `{{variables}}`, never har

People who liked this also viewed

6 picks

Type