API testing is now expected in most QA job descriptions, and Postman is usually the first tool testers learn for it. This Postman API testing tutorial takes you from zero to running an automated collection in nine practical steps, using a free public API so you can follow along right now.

You do not need prior coding experience. You will write a few lines of JavaScript for assertions, but every snippet is explained. By the end you will be able to send requests, validate responses, reuse values with variables and run your tests from the command line.

Key takeaways

• Organise requests into collections and use environments for URLs and tokens.
• Write assertions with pm.test and pm.expect in the post-response script.
• Chain requests by saving response values into variables.
• Run collections in CI with Newman or the Postman CLI.

What is API testing?

An API (Application Programming Interface) lets two systems talk to each other. When you open a shopping app, the screen calls APIs to fetch products, prices and your cart. API testing checks these calls directly — without the UI — for correct status codes, response data, error handling, security and speed. Because APIs are tested before the UI is ready, bugs are found earlier and tests run faster and more reliably than UI tests.

Method	Purpose	Typical success code
GET	Read a resource	200 OK
POST	Create a resource	201 Created
PUT	Replace a resource	200 OK
PATCH	Partially update a resource	200 OK
DELETE	Remove a resource	200 OK or 204 No Content

Postman API testing tutorial: 9 steps

Step 1: Install Postman and create a workspace

Download the desktop app or use the web version, then sign in with a free account. Create a workspace named “QA Practice” to keep your work organised.

Step 2: Create a collection

A collection is a folder of related requests. Click New → Collection and name it “JSONPlaceholder Tests”. We will use JSONPlaceholder, a free fake REST API built for practice.

Step 3: Send your first GET request

Add a request to the collection, keep the method as GET and enter this URL, then click Send:

GET https://jsonplaceholder.typicode.com/posts/1

Step 4: Read the response

Check four things in the response pane: the status (200 OK), the time in milliseconds, the body (a JSON object with userId, id, title and body) and the headers, such as Content-Type: application/json. These are exactly what your assertions will verify.

Step 5: Send a POST request with a JSON body

Create a new request, change the method to POST and use the URL https://jsonplaceholder.typicode.com/posts. In the Body tab choose raw and JSON, then paste:

{
  "title": "QA Jobs India",
  "body": "Learning Postman",
  "userId": 1
}

Click Send. You should get 201 Created with your data and a new id. JSONPlaceholder does not actually save it, which makes it safe for practice.

Step 6: Write test scripts (assertions)

Open the GET request, go to the Scripts tab and select Post-response (older versions call this the “Tests” tab). Add:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Response time is below 1000 ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

pm.test("Post id and userId are correct", function () {
    const data = pm.response.json();
    pm.expect(data.id).to.eql(1);
    pm.expect(data.userId).to.eql(1);
    pm.expect(data.title).to.be.a("string");
});

pm.test("Content-Type is JSON", function () {
    pm.response.to.have.header("Content-Type");
    pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

Send the request again and open the Test Results tab. Each pm.test appears as passed or failed. Try changing 200 to 404 to see a failure — it is good practice to confirm that a test can actually fail.

Step 7: Use environments and variables

Hard-coded URLs break when you switch between QA, staging and production. Create an environment named “Practice” with a variable baseUrl set to https://jsonplaceholder.typicode.com, select it in the top-right dropdown, and change the request URL to {{baseUrl}}/posts/1. To chain requests, save a value from one response and reuse it in the next:

// In the POST request's Post-response script
const created = pm.response.json();
pm.environment.set("postId", created.id);

// Then use it in another request URL:
// {{baseUrl}}/posts/{{postId}}

The same idea works for login flows: save the token from the login response and send it in the Authorization tab as a Bearer Token using {{token}}.

Step 8: Run the collection with the Collection Runner

Click the collection, choose Run, select the requests and the environment, and start the run. Postman executes every request in order and shows a pass/fail summary. You can also attach a CSV or JSON data file to run the same request with many inputs, which is useful for data-driven testing.

Step 9: Automate with Newman

Newman is Postman’s command-line collection runner, ideal for Jenkins or GitHub Actions. Export the collection and environment as JSON, install Node.js, then run:

npm install -g newman
newman run JSONPlaceholder_Tests.postman_collection.json \
  -e Practice.postman_environment.json \
  -r cli,junit --reporter-junit-export results.xml

The JUnit report can be published by your CI server. Postman also offers its own Postman CLI, which works similarly for teams using Postman’s cloud features.

What to test in every API

Once the mechanics are clear, the real skill is deciding what to check. Use this checklist for each endpoint you test:

• Status code: the right code for success and for each error, such as 400 for bad input, 401 for a missing token, 403 for no permission and 404 for a missing resource.
• Response body: correct values, data types, required fields present and no unexpected nulls.
• Schema: the structure matches the contract, which you can validate with a JSON schema in your script.
• Headers: content type, caching and security headers.
• Business rules: for example, an order total equals the sum of item prices after discount.
• Performance: response time stays within the agreed limit.

Negative tests matter as much as positive ones. Send a POST with a missing required field, an invalid data type, an extremely long string or an expired token, and confirm that the API returns a clear error message and the correct 4xx code instead of a 500 server error. A 500 response to bad input is usually a bug worth reporting, because the server should validate input rather than crash. Writing these cases in Postman also prepares you for API interview questions, where testers are often asked how they would test an endpoint they have never seen.

Common beginner mistakes

• Only checking the status code and ignoring the response body.
• Skipping negative tests such as missing fields, invalid tokens or wrong IDs.
• Hard-coding tokens and URLs instead of using environments.
• Sharing collections that contain real passwords or API keys.

For deeper reference, the official Postman Learning Center documents every feature. To see where API testing fits in your growth plan, read our software testing roadmap, and check how API skills affect pay in our guide to QA salary in India.

FAQs

Is Postman free to use?

Yes. The free plan covers everything in this Postman API testing tutorial. Paid plans add team collaboration and higher usage limits.

Do I need to know JavaScript?

Only basics. Most assertions follow a few patterns, and you can use the snippets panel to insert common tests.

Postman or REST Assured — which should I learn?

Start with Postman to understand APIs, then learn REST Assured (Java) if you want code-based API automation in a framework.

Can Postman do performance testing?

It offers basic load simulation, but dedicated tools such as JMeter or k6 are better suited for serious performance testing.

How do I show Postman skills on my resume?

Share a public collection or a GitHub repo with exported collections and a Newman run, and describe what you validated.

Conclusion

You have now completed a full Postman API testing tutorial: requests, assertions, variables, runs and CI automation. Practise on two or three public APIs, add negative tests, and put your collection on GitHub. Then visit the daily QA jobs page and filter for API testing roles to start applying.