Moving from Postman to .http files is not just a format conversion. Methods, URLs,
headers, query parameters, and common request bodies translate cleanly. Cloud workspaces,
scripts, tests, file-backed bodies, and some authentication modes do not. A safe migration
separates those two categories before anyone deletes a collection.
The goal is not a perfect mechanical clone of Postman. It is a small set of readable REST requests that live beside the code and still do the jobs your developers rely on.
1. Inventory what the collection really does
Start with one representative collection, not the entire workspace. List:
- folders and requests people still run;
- collection, environment, and global variables they reference;
- pre-request scripts and tests;
- authentication configuration;
- file-backed or binary request bodies;
- examples that contain useful response data.
Delete nothing yet. Mark unused requests instead of carrying years of collection history into the new files.
2. Export Collection v2.1 JSON
Use the collection's actions menu in Postman, choose Export, and select Collection v2.1. Save the JSON outside a public repository until you have checked it for credentials.
Collection variables can be present in the export, but external Postman environments are a separate concern. Record the non-secret variable names and move their values deliberately. The detailed checklist is in how to export a Postman collection.
3. Convert the request definitions
Open the browser-only Postman to .http converter and paste or drop the exported v2.0/v2.1 JSON. The tool converts representable folders, request names, methods, URLs, query parameters, headers, common bodies, variables, and auth into readable request blocks. Conversion happens in the browser; the collection is not uploaded.
Review every warning. In particular:
- scripts and tests need a new home;
- unresolved external environment variables need values or renamed placeholders;
- file uploads and unsupported body modes cannot become a portable text body;
- unsupported auth configuration should become explicit headers only after you understand it.
Karve itself does not import Postman collections. It opens the .http or .rest output
after you save it.
4. Rebuild environments without committing secrets
Keep placeholders in the request file:
@baseUrl = http://localhost:5080
### Current user
GET {{baseUrl}}/api/me
Authorization: Bearer {{token}}
Put real values in a git-ignored dotenv file and commit only an .env.example with safe
placeholders. In Karve, register the environment and make it active before sending. A
file-level @variable overrides the active environment value.
Do not translate an OAuth pre-request script into invented Karve UI. Karve authentication is header-based: obtain the token through an appropriate external flow, then reference it as a variable in the header.
5. Decide where scripts and tests belong
For every Postman script, identify the behavior rather than copying JavaScript blindly:
| Existing behavior | Sensible destination |
|---|---|
| Response assertion | Unit, integration, or contract test |
| CI collection run | Existing test project or purpose-built CLI workflow |
| Signature calculation | Small reviewed script or application helper |
| Token retrieval | Explicit external auth flow; inject the resulting token |
| Request chaining | Keep the workflow elsewhere; Karve does not chain responses |
This is the part that requires engineering judgment. A converter should warn about it, not claim to automate it.
6. Validate and run a safe sample
Pass the generated file through the .http validator. Then run one GET and one representative write request against localhost or a development environment. Check the URL, query string, headers, body, authentication, and response — not just whether the server returned a status code.
Compare important requests with Postman during the transition. Keep the original export until the new file has been reviewed and the team knows where any displaced behavior lives.
7. Put the files beside the code
Create a predictable http/ folder or place each file beside the feature it exercises.
Commit it in the same pull request as any supporting tests or documentation. The guide to
storing API requests in Git covers names, .gitignore,
review rules, and multi-repo organization.
Once the files are in Git, developers can run them in Visual Studio, VS Code REST Client, JetBrains HTTP Client, or a dedicated client. Karve adds a native Windows workspace, dotenv environment switching, and local persistent history without taking ownership of the files. If you are deciding whether that simpler model fits, read Postman collections vs .http files and the Karve vs Postman comparison.