cURL converter for API tests

The quickest way to reproduce a request exactly is to copy it from the place it already works. In Chrome or Edge, open DevTools, select the Network panel, right-click the request and choose Copy, then Copy as cURL. On Windows, Chrome offers two versions: "Copy as cURL (bash)" for Git Bash, WSL or a Mac, and "Copy as cURL (cmd)" for the Windows command prompt, which escapes characters with ^. Firefox has the same menu with POSIX and Windows variants. This converter reads both formats.

In Postman, open the request and select the code icon in the right-hand sidebar, then choose cURL from the list. API documentation and support tickets often include curl examples too, and those convert in the same way.

A browser export carries everything the browser sent: session cookies, sec-ch-ua and sec-fetch headers, cache validators such as If-None-Match, and an accept-language. Most of that does not belong in an API test. The option to leave out browser-only headers removes the ones that describe the browser rather than the request, and the parsed view shows what was left out and why, so nothing disappears silently.

curl is quiet about some of what it sends, which is why a hand-written conversion often differs from the original. These are the parts that matter and how each one appears in code.

All four send a request body, and the differences explain a lot of "it works in curl but not in my test". -d, also written --data or --data-ascii, sends the text as given, but when the value starts with @ it reads a file and strips carriage returns, line breaks and null bytes from it. --data-binary @file sends the file exactly as it is. --data-raw is -d without the special meaning of @, which is why browsers use it: a body that happens to start with @ is still sent as text.

Several -d flags are joined with &, so -d a=1 -d b=2 sends a=1&b=2. None of them encode anything. If a value contains a space or an ampersand, use --data-urlencode, which percent-encodes the value: everything after the first =, or the whole argument when there is no =.

The common mistake is sending JSON with -d and no Content-Type header. curl then labels the JSON as application/x-www-form-urlencoded, and many frameworks reject it or parse an empty body. --json, added in curl 7.82.0, avoids this: it sends the data as given and sets both Content-Type: application/json and Accept: application/json. The converter warns when a JSON body would go out with the form type.

A converted request on its own is a script: it proves the call can be made, not that the answer is right. Every test output here includes an assertion on the status code, which is the minimum. Set the expected status before you copy, for example 201 for a create or 404 for a deliberate miss. Cypress fails a cy.request on any status outside 2xx and 3xx, so for an expected 4xx or 5xx the code adds failOnStatusCode: false.

Then assert on what the response means. Check the fields the client relies on and their types, not only that a body came back: an order total that becomes a string, or a list that comes back empty, passes a status check. For data that changes on every call, such as IDs and timestamps, assert the format rather than the value.

In k6, a failed check is recorded but does not stop the script or fail the run on its own. Add a threshold such as checks: ['rate==1.0'] to the options when the check should fail the test.

A copied request carries live credentials: a bearer token, a session cookie, an API key. Pasted into a test file, they end up in version control, in CI logs and in the history of every branch. With "Move secrets to environment variables" on, the converter replaces Authorization, Cookie, API-key and token headers, secret-looking query parameters such as api_key, and -u credentials with lookups in the idiom of each language: os.environ in Python, process.env in Node and Playwright, cy.env in Cypress, System.getenv in Java and __ENV in k6.

The scheme stays in the code and only the credential moves, so Authorization: Bearer becomes "Bearer " plus API_TOKEN. The list under the code shows which variables to set. In CI, store them as secrets in your pipeline. Locally, a .env file that is listed in .gitignore keeps them off the repository.

os.environ[...] in Python raises an error when a variable is missing, which is what a test should do: fail at once, rather than send an empty token and report a confusing 401. Cypress reads operating system variables only when they carry the CYPRESS_ prefix, so API_TOKEN is set as CYPRESS_API_TOKEN.

Playwright's request fixture is a good fit when the team already writes Playwright tests. API calls can set up data before a UI test, check the backend after one, and run in the same report and the same CI job. The fixture uses the baseURL and extraHTTPHeaders from the Playwright config, and page.request shares cookies with the browser context, so an API call can act as the user who is logged in on the page.

A dedicated tool earns its place when the API suite is the main product. REST Assured suits Java teams that want API tests next to the service code, with JSON path and schema assertions. Postman and its collections suit exploratory work and sharing requests with developers. k6 is for load: the same request run by many virtual users, with thresholds on latency and error rate rather than a single pass or fail.

Whichever you choose, keep the request and its assertions together and parameterise the base URL, so the same test runs against a local build, staging and production smoke checks.