SkilsMVP

Postman guide

API testing with Postman for QA engineers

Most apps communicate through APIs. QA engineers test APIs to catch bugs before they affect the UI — and to test backend logic directly. Here is everything you need to get started.

What is API testing and why QAs do it?

An API (Application Programming Interface) is the channel through which the frontend and backend of an app communicate — and through which external services talk to each other. When a user submits a form, clicks a button, or loads a page, one or more API calls happen behind the scenes.

QA engineers test APIs directly — without going through the UI — to catch backend bugs earlier, test edge cases the UI does not expose, and verify that the backend contract matches what the frontend depends on. A defect found at the API layer is faster and cheaper to fix than one found after it reaches production.

What is Postman?

Postman is a free desktop tool for sending HTTP requests and inspecting API responses. It is the standard QA tool for API testing — you will see it listed in job descriptions for QA engineers at companies of every size. With Postman you can send requests, inspect responses, write test assertions, organize tests into collections, and run full regression suites against any environment.

HTTP basics every QA must know

Every API request uses an HTTP method that describes the action being performed.

GET

Read

Retrieve data from the server. No body required. Use for fetching a list of items, getting a single record, or reading current state.

POST

Create

Send data to create a new resource. Requires a request body (usually JSON). The server returns the created object and a 201 status.

PUT / PATCH

Update

Modify an existing resource. PUT replaces the full object; PATCH updates only the fields you send. Both require an ID in the URL and a body.

DELETE

Delete

Remove a resource by ID. Usually returns 200 or 204 (No Content) on success. Confirm the resource is gone with a follow-up GET.

Every request also has three parts to understand:

  • URL: The endpoint address — where the request goes.
  • Headers: Metadata sent with the request, most commonly the Authorization header containing a token or API key.
  • Body: The JSON payload sent with POST, PUT, and PATCH requests — the data you want to create or update.
  • Params: Query string values appended to the URL (e.g. ?page=2&limit=20) that filter or paginate results.

Status codes tell you what happened. These seven cover 95% of what you will encounter.

200
OK — Request succeeded. The response body contains what you asked for.
201
Created — A new resource was successfully created. Returned after a successful POST.
400
Bad Request — The request was malformed — missing a required field, wrong data type, or invalid value.
401
Unauthorized — No valid credentials were supplied. Add an authorization header or log in first.
403
Forbidden — Credentials are valid but this user does not have permission to access the resource.
404
Not Found — The resource does not exist at this URL. Check the ID or endpoint path.
500
Server Error — Something went wrong on the backend. This is a bug — not a problem with your request.

Your first API test in Postman

Follow these five steps to send your first request and write your first assertion.

  1. 1

    Install Postman

    Download Postman for free at postman.com. No account required to get started — just install and open the desktop app.

  2. 2

    Create a new request

    Click the + tab to open a new request. Select GET from the method dropdown. You are now ready to send your first request.

  3. 3

    Try a free public API

    Enter this URL: https://jsonplaceholder.typicode.com/posts — then click Send. This public test API returns 100 fake blog posts in JSON format. No authentication needed.

  4. 4

    Check the response

    Three things to verify immediately: status code is 200 (bottom of the response panel), response time is under 500ms (shown next to the status code), and the body contains an array of 100 post objects.

  5. 5

    Add a test assertion

    Click the Tests tab (next to Body and Headers in the request panel). Paste this assertion and click Send again — the Tests Results panel at the bottom will show Pass or Fail.

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

Test assertions to write

Every API request you test should have at least these five assertions covering the most common failure modes.

Status code is correct

Always verify the HTTP status code before checking anything else. A 200 when you expected a 201 (or vice versa) is a real bug — the API contract is not being followed.

Response time is acceptable

Set a threshold (typically under 2 seconds for standard operations, under 500ms for critical paths). Slow responses affect user experience and can indicate backend performance problems.

Response body contains expected fields

Verify that required fields are present in every response — even if their values are empty. A missing field that the frontend expects to render will cause a crash.

Response body values match expected data

For deterministic requests (GET by ID, create with known input), assert that the actual values match what you sent or what you know should be stored.

Error responses return correct messages

Test the unhappy paths deliberately. Send a bad request, an expired token, or a missing required field. Verify that the error message, code, and structure match the API specification.

Organizing tests

Individual requests get you started. Collections, environments, and the Runner turn your requests into a repeatable test suite.

Collections

Group related requests

A collection is a folder of saved requests. Create one collection per feature or service — for example, 'Auth API' or 'User Profile API'. Collections let you run all requests in sequence and share test suites with your team.

Environments

Switch between dev / staging / prod

Environments store variables like base URLs and API keys. Create one environment per deployment stage. When you switch environments, every request automatically uses the correct URL — no find-and-replace required.

Collection Runner

Execute a full collection automatically

The Runner executes every request in a collection in order, runs all assertions, and produces a pass/fail report. Use it before a release to verify the full API surface in one click.

Ready to go deeper?

Practice QA skills in the QA Engineer track

Postman is one tool in the QA engineer toolkit. Learn test planning, bug reporting, test case design, and more in the full QA Engineer learning path.

Go to QA Engineer track