Postman for API Testing — Getting Past Curl

What Postman Solves That curl Doesn't

Every working API engineer learns curl first. It is on every machine, it is universal, it is fast for one-off requests. Then they hit the real problems that come with real API work — authenticating to ten different services, switching between dev and production, calling the same request twenty times with different parameters, sharing a working request with a teammate, debugging why something works in one environment but not another. curl solves none of these.

Postman is the tool that does. It started as a Chrome extension a decade ago and has become the default API workbench for engineers everywhere. Free for individuals, fast to install, and has a learning curve that pays back within an afternoon. This article is what Postman is, when to reach for it instead of curl, and the small set of features you actually need to know.

Two Use Cases, One Tool

Postman gets used in two distinct ways and the documentation rarely separates them clearly:

Use case 1: Exploring an API. You are integrating with Stripe, or hitting your own backend in development, or testing a partner's API. You need to send requests, see responses, tweak parameters, save working examples, and share them. This is the bulk of what most engineers do with Postman.

Use case 2: API testing automation. You want to run a sequence of requests as a regression test — does the auth endpoint still work, does creating a user still return a 201, does deleting a non-existent resource still return a 404. Postman has a Newman CLI runner that turns saved request collections into automated test suites in CI.

Most engineers start with use case 1 and graduate to use case 2 over time. We will focus on use case 1 here because it is what you will use first; use case 2 builds naturally on top.

Installing and the First Five Minutes

Download Postman from postman.com/downloads for your OS. Sign up for a free account when prompted (the free tier is generous and lets you sync collections across devices, which is the practical reason to make an account).

The window has three main panes: the left sidebar (collections, history, environments), the central tabbed area (current request and response), and the right panel (request details when you need them). It feels like a code editor for HTTP requests.

Make your first request:

1. Click "+" to open a new request tab.
2. Set the method dropdown to GET.
3. Type the URL: https://api.github.com/users/torvalds
4. Click "Send."

You see Linus Torvalds's GitHub profile data in the response panel — JSON pretty-printed, syntax-highlighted, with response time and status code in the header. Postman is now a working tool for you.

Saving Requests Into Collections

The single most useful Postman feature is collections — folders of saved requests that you can name, organize, share, and re-run. The discipline of saving working requests pays back the moment you have to come back to a project two weeks later and remember the exact endpoint shapes.

To save the GitHub request:

1. Click "Save" in the request tab.
2. Pick or create a collection (e.g., "GitHub API exploration").
3. Name the request ("Get user by username").
4. Click "Save."

The request now lives in the sidebar permanently. Click it; the request loads. Re-run, edit, fork into a similar request — all from the saved version. This is the primary way Postman becomes a knowledge base of how every API you touch actually works.

A typical professional engineer ends up with collections per project, organized in folders by feature area:

Stripe Integration
├── Customers
│   ├── Create customer
│   ├── Get customer
│   └── Update customer
├── Charges
│   ├── Create charge
│   └── Refund charge
└── Webhooks
    ├── Verify signature
    └── Handle event

Six months later, a new engineer joins the team. You share the collection. They have a complete map of every endpoint your code talks to, with working examples — better documentation than the API provider's own docs, because it is annotated for your specific use case.

Environments — The Single Best Feature

You have a dev, a staging, and a production API. Each has a different base URL, different API keys, different test data. In curl, you copy-paste the URL and re-edit the auth header every time you switch. In Postman, you create environments — named sets of variables — and switch between them with one dropdown.

Set up an environment:

1. Click "Environments" in the left sidebar.
2. Click "Create Environment." Name it "Dev."
3. Add variables:
   • baseUrl = https://api-dev.example.com
   • apiKey = sk_test_abc123...
4. Save.

Then in your requests, use {{baseUrl}} and {{apiKey}} instead of literal values:

URL: {{baseUrl}}/posts/42
Header: Authorization: Bearer {{apiKey}}

Switch environments with the dropdown in the upper right. The same request now hits dev, staging, or production depending on what is selected. This single feature replaces about an hour a week of "wait, am I looking at staging or prod" debugging.

The variables can also be secrets. Postman has a secret vault that masks them in the UI and excludes them from collection exports. API keys belong in secrets, never in the request URL or body literally.

Authentication

Most APIs require authentication. Postman supports every common auth scheme natively — you do not write the auth header by hand.

In any request, click the "Authorization" tab and pick the type:

• Bearer Token — most modern APIs (Authorization: Bearer xxxxx).
• Basic Auth — username + password (less common now but still around).
• API Key — header or query param, configurable.
• OAuth 2.0 — full flow with redirect URLs and token refresh. Postman walks you through the entire dance.
• AWS Signature — for AWS service APIs.
• Custom — write your own pre-request script if the API uses something exotic.

Set up Bearer Token once with {{apiKey}} as the value. Save. Every request in the collection inherits the auth (you can override per-request). The auth complexity that takes 30 minutes to get right with curl is two clicks in Postman.

Pre-Request Scripts and Tests

Some APIs need an auth token that expires every hour. The pattern in Postman is a pre-request script that runs before each request. JavaScript runs in a sandbox and can set environment variables, refresh tokens, or compute signatures.

// Pre-request script
if (!pm.environment.get('accessToken') || tokenExpired()) {
  pm.sendRequest({
    url: pm.environment.get('baseUrl') + '/auth/refresh',
    method: 'POST',
    body: { mode: 'raw', raw: JSON.stringify({ refreshToken: pm.environment.get('refreshToken') }) },
  }, (err, res) => {
    pm.environment.set('accessToken', res.json().access_token)
  })
}

The request then uses {{accessToken}} and the script keeps it fresh automatically.

Similarly, test scripts run after each response and can verify the response shape, status code, or specific fields:

pm.test('Status is 200', () => {
  pm.response.to.have.status(200)
})

pm.test('Response has user id', () => {
  const json = pm.response.json()
  pm.expect(json.id).to.be.a('number')
})

These are basic JavaScript assertions. Run a collection through Postman's runner and you get a pass/fail summary across all requests. This is how use case 1 turns into use case 2.

Newman — Postman in CI

The same collection that you use interactively can run in CI. Postman exports the collection as a JSON file. The newman CLI runs it:

npm install -g newman

# Run a collection
newman run my-collection.json -e dev-environment.json

# In CI (GitHub Actions example)
newman run my-collection.json \
  -e production-environment.json \
  --reporters cli,junit \
  --reporter-junit-export results.xml

A passing CI run means every request in the collection got a 2xx response and every test assertion passed. A failing run shows you exactly which request broke and why. This is a real regression test for your API endpoints, run on every deploy, with no test-framework setup beyond the Postman collection you already had.

Postman Versus the Alternatives

A practical comparison:

Postman is dominant for a reason — features, polish, ecosystem, and the network effect of "everyone has Postman." Insomnia and Bruno are sensible alternatives for engineers who want pure open-source tools or text-file-based collections that work cleanly with Git. For raw speed on one-off requests, curl and HTTPie still win.

For learning APIs, Postman is the right first tool. Branch out as your needs warrant.

Where This Fits

Lesson 09 of the ABCsteps curriculum has you call APIs you do not own — exploring, debugging, integrating. Postman is the workbench the lesson uses for that exploration. With this article in your head, the lesson's instructions about "save this in a collection, switch the environment, run the test script" all make sense as named features instead of ritual. By the end of lesson 09, you will have a Postman collection of working requests for the project, which becomes living documentation for the next person who touches it.