Manual API testing with Postman

Knowing what an HTTP request is, you need a way to send one by hand and read the response — without an app, without writing code. That tool is Postman (or a similar API client: Insomnia, Bruno, or the REST client built into your editor). It lets a QA craft a request, fire it, and inspect exactly what comes back, which is how manual API testing is actually done. This lesson is testing an API by hand with Postman.

What Postman is, and why a QA uses it

Postman is a desktop app for sending HTTP requests and reading responses. You fill in the method, URL, headers and body; press Send; and it shows you the status code, the response body (pretty-printed JSON), the headers, and the time it took. That is the whole loop, and it is enormously useful:

You test the API directly, with no app in the way — so a bug you find is in the API, not the screen.
You can send anything — including the invalid requests the app's UI would never let you make, which is exactly where bugs hide.
You can save requests, organise them into collections, and re-run them — the beginning of a reusable manual test suite.

Every mobile and web app you test has an API behind it, and Postman is how you reach it.

Sending your first request

The loop is simple:

Choose the method from the dropdown (GET, POST, …).
Type the URL, e.g. https://api.example.in/transactions.
For a GET, add query parameters in the Params tab (status=pending) — Postman builds the ?... for you.
For a POST/PUT, set the body: choose raw + JSON, and type the JSON:
```
{ "amount": 500, "to": "9876543210" }
```
Add headers if needed — Content-Type: application/json (Postman often adds this for a JSON body), and Authorization once you are testing authenticated endpoints (the auth lesson).
Press Send, and read the response: status code first (is it the 2xx/4xx you expected?), then the body (is the data right?), then the time (is it reasonable?).

That send-and-read loop, with deliberately chosen inputs, is manual API testing. You are doing at the API exactly what you did through the UI in the manual-testing module — positive, negative and edge cases — but faster and closer to the logic.

Variables and environments: don't hard-code

Real testing happens against more than one server — your local machine, a test/staging server, sometimes production (read-only!) — and with values that change (a token, an id). Hard-coding them into every request is how you end up firing a test request at the wrong server. Postman's answer:

Environments — a named set of variables (a "test" environment, a "staging" one). Put the server in a variable {{baseUrl}} and write URLs as {{baseUrl}}/transactions. Switch environment, and every request now targets the other server — no editing, no accidents.
Variables — for tokens, ids and other values that change or repeat. Store the auth token in {{token}} and reference it in the header, so you update it in one place.

This is not polish — it is how you avoid the genuinely dangerous mistake of running a write request meant for test against production. Use a {{baseUrl}} variable from your very first request.

Collections: a reusable manual test suite

A collection is a saved, organised group of requests. As you test an API you save each useful request (create a transaction, fetch it, list them, try an invalid amount) into a collection, grouped in folders. This gives you:

Repeatability — re-run the same requests next release instead of re-typing them (the beginning of regression testing at the API).
Documentation — the collection is a record of how the API behaves and what you tested.
A path to automation — Postman can run a whole collection at once, and even in CI (via Newman, its command-line runner). A well-built manual collection is a step towards the automated API suite (the api-automation module).

So even manual API testing leaves something durable behind: a collection you and the team keep.

Reading the response critically

The point of Postman is not to send requests — it is to judge the responses, and a QA judges more than "did it work":

Status code — the expected one, and the right one for the case (a 400 for bad input, not a 200 or a 500 — the http lesson).
Body correctness — are the values right? Cross-check against what you sent and what the data should be. A 200 OK with wrong numbers in the body is still a bug.
Error messages — on a 4xx, is the message clear and useful (does it say what was wrong), or vague/ leaking internal detail (a stack trace in the response is a bug and a security issue)?
Consistency — does the same kind of error return the same shape of response across endpoints?
Time — is the response reasonably fast, or suspiciously slow?

The habit that matters: do not accept a green "200". Read the body and confirm it is actually correct. Postman makes the response easy to read precisely so you can check it, not just glance at the status.

Check your work

What Postman is. A client to send HTTP requests and read responses (status, body, headers, time), testing the API directly with no app in the way — including the invalid requests a UI would never allow.

The loop. Method → URL → params/body (raw JSON) → headers → Send → read status, then body, then time. Manual API testing is this loop with deliberately chosen positive/negative/edge inputs — the module-2 techniques, at the API.

Variables/environments. Use a {{baseUrl}} variable and named environments (test/staging) so switching servers is one click and you never fire a write request at production by accident; store tokens/ids in variables.

Collections. Save requests into an organised collection for repeatability (regression), documentation, and a path to automation (Newman/CI).

Read responses critically. Check the right status code, the body's actual correctness (a 200 with wrong data is a bug), clear non-leaking error messages, consistency, and response time. Never accept a green 200 without reading the body.

Practice

Install Postman (or Insomnia/Bruno) and send a GET to any public API; read the status, body and time.
Send a POST with a JSON body to a create endpoint (use a test API); confirm you get a 201 and the created record in the body.
Set up an environment with a {{baseUrl}} variable and rewrite your requests to use it; switch the variable and confirm every request now targets the other URL.
Deliberately send an invalid body (missing a required field, a bad type) and check you get the right 4xx with a clear message — not a 200, not a 500.
Save your requests into a collection with folders; describe how you would re-run it next release as regression.
Take one 200 response and verify the body is actually correct against what you sent — not just that the status was green.

Official documentation

Postman — Sending your first request — The send-and-read loop, step by step.
Postman — Using variables — Variables and environments, and why to use them.
Postman — Collections — Organising, saving and re-running requests.

Next: designing API test cases — positive, negative and edge.