Skip to content
Back to skills

Postman Openapi Converter

ASecurity

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\",...

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 12, 2026
ai-agentsgogitapisecuritydocumentation

Works with

  • api

Security analysis

A100/100

Scanned September 12, 2026

npx -y skills add thedixitjain/the-mega-skill-library --skill postman-openapi-converter --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Postman Openapi Converter?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Postman Openapi Converter
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/thedixitjain-postman-openapi-converter/badge)](https://www.skillsdirectory.com/skills/thedixitjain-postman-openapi-converter)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: postman-openapi-converter
description: "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\",..."
category: general-purpose
source_repo: sickn33/agentic-awesome-skills
source_path: "skills/postman-openapi-converter/SKILL.md"
source_url: https://github.com/sickn33/agentic-awesome-skills/blob/HEAD/skills/postman-openapi-converter/SKILL.md
---


# OpenAPI → Postman Collection Converter
## When to Use

Use this skill when you need 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",...


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 3
- `swagger: "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 → `"user@example.com"`, `"date-time"` → `"2024-01-15T10:30:00Z"`)
- For `$ref` schemas, 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 `tags` into folders
- Include `description` field on each request from `operationId` + `summary` + `description`
- Add saved example responses where `responses` are defined in the spec

```json
"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_url` from `servers[0].url` or `host + basePath`
- `token`, `api_key`, `username`, `password` as empty placeholders
- Any server variables from `servers[0].variables`

---

## Step 7 — Output

1. `collection.json` — Full Postman Collection v2.1
2. `environment.json` — Matching environment file
3. **Conversion summary**: number of endpoints converted, folders created, auth type detected, any fields skipped or approximated
4. Import instructions

---

## Edge Cases

- **`$ref` chains**: Resolve all `$ref` pointers inline before mapping
- **`allOf` / `oneOf` / `anyOf`**: Use the first/primary schema for body generation; note alternatives in description
- **Path parameters**: Convert `{param}` to `:param` in URL path AND add to `variable` array 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 `paths` entry produces at least one request
- [ ] Path params use `:param` format in Postman URL
- [ ] All `$ref` resolved — no raw `$ref` strings 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

---

## Limitations

- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

---

**Source:** [`sickn33/agentic-awesome-skills`](https://github.com/sickn33/agentic-awesome-skills) → `skills/postman-openapi-converter/SKILL.md`

**Also appears in:** `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills/skills/postman-openapi-converter/SKILL.md`, `sickn33/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/postman-openapi-converter/SKILL.md`

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.