How to generate .http files from an OpenAPI spec

Every documented API already contains its own request collection — the OpenAPI spec lists each operation's method, path, parameters, auth scheme, and example bodies. Converting that spec into .http files gives you a runnable, diffable starting point in minutes, instead of hand-writing requests one endpoint at a time. Here's the workflow end to end.

1. Get the spec as JSON

Most ASP.NET Core, FastAPI, Spring, and Express services publish their spec at a well-known route — typically /swagger/v1/swagger.json, /openapi.json, or linked from the Swagger UI page. Save it locally. Both OpenAPI 3.x and Swagger 2.0 work.

One catch: if the spec is YAML, convert it to JSON first (any yaml to json tool, or your framework usually serves a JSON variant directly). The converter below is deliberately JSON-only.

2. Convert it in the browser

Open the free OpenAPI → .http converter and paste or drop the spec. Everything runs client-side — the spec never leaves your browser, which matters when it describes internal APIs.

What comes out:

• one ### block per operation, titled from the operation's summary;
• a @baseUrl variable from the spec's server URL, used as {{baseUrl}} in every request;
• path parameters as {{variables}} with declarations collected at the top;
• required query parameters (turn on Include optional query params if you want the full surface);
• example request bodies generated from the spec's schemas and examples (Example request bodies, on by default);
• auth headers derived from the spec's security schemes — Authorization: Bearer {{token}}, Basic, or an API-key header.

Read the conversion notes: anything the spec asks for that a text request can't represent is reported, not silently invented.

3. Make it runnable

The generated file is a starting point with honest placeholders. Three edits make it live:

@baseUrl = https://localhost:7220
@token = 

### List pets
GET {{baseUrl}}/pets?limit={{limit}}
Authorization: Bearer {{token}}

1. Point @baseUrl at the environment you actually target (or better: move it to a .env environment so one file serves dev and staging).
2. Fill auth values in the .env, never in the committed file — the auth guide shows the pattern per scheme.
3. Replace schema-generated example bodies with realistic data where it matters — the request-bodies guide covers JSON and form payloads.

Then run it through the .http validator if you've edited heavily — it catches malformed headers and undeclared variables before your teammates do.

4. Split, commit, and keep it fresh

One spec often produces one long file. Split it by resource (orders.http, customers.http) and commit the files next to the service they exercise — the Git layout guide makes the case. When the API changes, regenerate and diff: the spec moved, your requests show exactly where.

From there the files work in any .http-aware tool. Karve gives them a native Windows workspace — organized across repos, with environments, tabs, and persistent history — and the examples gallery has fifteen reviewed .http recipes if you'd rather start from working requests than from a spec.

Frequently asked

Does this replace Swagger UI? Different job. Swagger UI explores an API interactively; .http files are repeatable, reviewable requests that live in Git and run in your tools every day.

What about YAML specs? Convert to JSON first — the tool tells you the same if you paste YAML. Frameworks almost always serve a JSON variant of the same document.

My spec has no examples — what bodies are generated? The converter builds an example from the schema itself: enums pick their first value, objects walk their properties, primitives get format-aware placeholders. Treat the result as a scaffold and put real data where it counts.

---

Coming from a Postman collection instead of a spec? The Postman → .http converter and migration guide cover that path.