WebStorm's HTTP Client: Ditch Postman for Quick API Checks

The problem: your API tests live outside your code

You are debugging a frontend, the API returns a 500, and you need to check if the backend is down or your request is wrong. You could open Postman, but your Postman workspace is a mess of unsaved requests, and the last time you tried to share a collection with a teammate, you ended up exporting JSON and pasting it into Slack.

WebStorm has a built-in HTTP Client that lets you write requests in plain text files, run them with a click, and commit them to git. It is not a full Postman replacement, but for everyday API checks, it is often enough.

How it works

Create a file named api.http in your project. Write requests using the REST Client convention: method, URL, headers, body. Separate multiple requests with ###. Click the run icon in the gutter next to any request. The response appears in a tool window with formatted JSON, headers, and cookies.

Variables like {{host}} come from an http-client.env.json file. You can define environments for dev, staging, and prod, then switch between them via the run configuration dropdown. Response handler scripts in JavaScript can assert on status codes, capture values into global variables, and chain requests together.

A worked example: login, then fetch

Here is a two-request file. The first request logs in and captures a token. The second uses that token to fetch user data.

POST {{host}}/login
Content-Type: application/json

{
  "username": "[contact removed]",
  "password": "secret"
}

###

GET {{host}}/user
Authorization: Bearer {{token}}

The response handler for the login request might look like this:

client.test("login succeeded", function() {
  client.assert(response.status === 200, "Expected 200, got " + response.status);
  client.global.set("token", response.body.token);
});

If the login request returns a JSON body with a token field, that token is now available as {{token}} in the next request. You can re-run the user fetch as many times as you like, and the token persists.

What you give up

The HTTP Client is lightweight, but it is not a full API platform. There are no mock servers, no automated collection runner with rich reporting, and no team-synced cloud workspaces. If you need to share a Postman collection with a team, you will still need to export it. The client also lacks gRPC and WebSocket support in some versions, so check your IDE version before planning a workflow around it.

Secrets are another risk: http-client.env.json can hold credentials, and committing it with real passwords is a common mistake. Use the private environment file convention for sensitive values, and add it to .gitignore.

Try it now

Create demo.http, add GET https://httpbin.org/get, and click the run icon. If it works, add a second request separated by ### and an http-client.env.json with a {{host}} variable. Switch environments via the run configuration dropdown to verify variable substitution.

For a simple assertion, write a response handler script using client.test() to check a 200 status. If it passes, you have a working setup. If it fails, check the response view for details.

Limitations and a practical check

The HTTP Client is not a full replacement for dedicated API platforms. It lacks features like mock servers, automated collection runners with rich reporting, and team-synced cloud workspaces. Exact capabilities vary by IDE version, so examples from older tutorials may not behave identically. Environment files can hold secrets; committing http-client.env.json with real credentials is a common mistake—use the private env file convention for sensitive values.

To verify the result, create a file named demo.http in a WebStorm project, add GET https://httpbin.org/get, and click the gutter run icon to confirm the request executes and shows a response. Add a second request separated by ### and an http-client.env.json with a {{host}} variable, then switch environments via the run configuration dropdown to verify variable substitution. Write a small response handler script using client.test() to assert a 200 status and confirm it passes or fails as expected in the response view.