API Tools Tools

Convert cURL commands into request code, and convert between Postman collections and OpenAPI specs.

cURL to Python

Convert a cURL command into a Python requests call.

cURL to Go

Convert a cURL command into a Go net/http request.

cURL to Node.js

Convert a cURL command into a Node.js fetch call.

cURL to PHP

Convert a cURL command into a PHP curl_setopt call.

cURL to Rust

Convert a cURL command into a Rust reqwest request.

Postman to OpenAPI

Convert a Postman collection into an OpenAPI 3.0 spec.

OpenAPI to Postman

Convert an OpenAPI 3.0 spec into a Postman collection.

Swagger 2.0 to OpenAPI 3.1

Convert a Swagger 2.0 spec into OpenAPI 3.1.

cURL to Postman Collection

Convert a cURL command into a Postman collection.

cURL to JavaScript (fetch)

Convert a cURL command into browser-ready JavaScript using fetch.

cURL to Java

Convert a cURL command into a Java HttpClient request.

cURL to C#

Convert a cURL command into a C# HttpClient request.

Postman to Insomnia

Convert a Postman collection into an Insomnia export.

Insomnia to Postman

Convert an Insomnia export into a Postman collection.

This category covers two related but distinct workflows: turning a single cURL command into request code for a specific language, and converting between the collection formats (Postman, Insomnia, OpenAPI) that teams use to organize and share whole sets of API requests.

The cURL converters — to Python, Go, Node.js, PHP, Rust, and a Postman collection — all share one parser that reads a cURL command's method, URL, headers, body, form fields, and basic auth, then hand that parsed structure to a per-language emitter. That split matters for correctness: the parsing logic (and its edge cases — quoted arguments, -d vs. --data-raw, multipart -F fields) is written and tested once, not reimplemented six times with six chances to disagree on what a flag means. Every emitter passes the request body through as a raw string rather than re-parsing it as a language-native object, which mirrors what cURL itself does — byte passthrough — and avoids an entire class of "reconstructed the JSON body wrong" bugs at the cost of slightly less idiomatic output.

The collection converters — Postman↔OpenAPI, Postman↔Insomnia — move between formats with genuinely different data models, not just different syntax for the same thing. OpenAPI describes an API's shape (paths, schemas, parameters, response types) as documentation-first; a Postman collection describes a set of concrete requests someone actually made, often with environment variables and pre-request scripts that have no OpenAPI equivalent at all. Converting Postman → OpenAPI can only infer a schema from the concrete request/response examples in the collection — it won't recover parameter constraints or descriptions that were never in a Postman request to begin with. Converting the other way, OpenAPI → Postman, generates one concrete request per path/method/example but skips anything OpenAPI expresses that Postman has no field for, like complex oneOf/anyOf schema unions — those get flattened to the closest single-shape approximation rather than a fabricated Postman construct that doesn't exist.