Complete API Testing Tutorial

API testing validates an application's business logic and data at the service layer — directly against its endpoints, below the user interface. It's faster, more stable and catches defects earlier than UI testing, which is why it's a core skill for every modern QA engineer and SDET.

This tutorial teaches API testing from zero: how APIs and HTTP work, what to validate, how to design test cases, and how to write your first tests in Postman. Each section links to a full tutorial so you can go deeper in order.

Advertisement

What Is API Testing and Why Does It Matter?

An API (Application Programming Interface) is how software components talk to each other. When you log in to an app, the screen sends a request such as POST /api/login to a server, and the server replies with a response. API testing sends those requests directly and checks the responses — no browser involved.

  • Earlier feedback — APIs are often ready before the UI, so testing can start sooner.
  • Faster and more stable — an API test runs in milliseconds and doesn't break when a button moves.
  • Better coverage — you can test edge cases, invalid data and error handling that are hard to reach through the UI.
  • The middle of the test pyramid — many teams keep most automated checks at the API level and a smaller set of UI tests on top.

More background in API Testing Fundamentals and REST vs SOAP.

How an API Request and Response Work

Every REST API call has the same parts. Here is a raw HTTP request that creates a user:

POST /api/users?notify=true HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{ "name": "Asha", "email": "asha@example.com" }
  • Method — POST: what to do.
  • Endpoint — /api/users: which resource.
  • Query parameter — ?notify=true: optional filters or options. (A path parameter is part of the URL itself, like /api/users/42.)
  • Headers — metadata such as authentication and content type.
  • Body — the data sent, usually JSON.

And the server's response:

HTTP/1.1 201 Created
Content-Type: application/json

{ "id": 42, "name": "Asha", "email": "asha@example.com" }

The status code (201) says what happened, and the body returns the created resource. Full detail in HTTP Requests & Responses, query vs path parameters and JSON and XML.

HTTP Methods

Method Purpose Typical success code Idempotent?
GET Read a resource 200 OK Yes
POST Create a resource 201 Created No
PUT Replace a resource completely 200 OK / 204 No Content Yes
PATCH Update part of a resource 200 OK / 204 No Content Not guaranteed
DELETE Remove a resource 200 OK / 204 No Content Yes

Idempotent means sending the same request several times leaves the server in the same state as sending it once — an important thing to test for PUT and DELETE. See GET vs POST vs PUT vs PATCH vs DELETE.

Status Codes Every Tester Must Know

Code Meaning When you'll see it in testing
200 OK Success Successful GET, PUT or PATCH
201 Created Resource created Successful POST
204 No Content Success, empty body Often returned by DELETE
400 Bad Request Invalid input Missing or malformed fields
401 Unauthorized Not authenticated Missing, expired or invalid token
403 Forbidden Authenticated, but not allowed A normal user calling an admin endpoint
404 Not Found Resource doesn't exist GET for an ID that was deleted
409 Conflict State conflict Creating a user with an email that already exists
429 Too Many Requests Rate limit exceeded Load or abuse testing
500 Internal Server Error Unhandled server failure Almost always a bug worth reporting
503 Service Unavailable Server temporarily down or overloaded Deployments, dependency outages

Interviewers love 401 vs 403 and 500 vs 503. Keep the HTTP Status Codes Cheat Sheet handy, and read HTTP Methods & Status Codes.

What to Validate in an API Test

Checking only the status code is the most common beginner mistake. A complete API test validates:

  1. Status code — exactly the expected one (201, not just "2xx").
  2. Response body — correct values, not just that fields exist.
  3. Schema — field names, data types and required fields match the contract.
  4. Headers — Content-Type, caching and security headers.
  5. Response time — within the agreed limit.
  6. Error responses — clear messages and no stack traces or internal details.
  7. Side effects — the data really changed (check with a follow-up GET or a database query).
  8. Authorization — each role can do only what it should.

Designing API Test Cases: An Example

For an endpoint POST /api/users that creates a user, a solid set of test cases looks like this:

Scenario Type Expected result
Valid name and email Positive 201, body contains the new ID and the same data
Missing email Negative 400 with a clear validation message
Invalid email format Negative 400
Email already registered Negative 409 Conflict
No token / expired token Security 401
Token of a user without permission Security 403
Name at maximum length, and one character over Boundary 201, then 400
GET the new user afterwards Integration 200, data persisted correctly

Practise designing scenarios like these in the API Testing Scenario Lab, and see real-project questions in API Testing Project Questions.

Your First API Tests in Postman

Postman is the standard tool for manual and exploratory API testing. These examples use JSONPlaceholder, a free public demo API.

Test 1 — GET a resource

Create a request GET https://jsonplaceholder.typicode.com/posts/1, open the Tests (post-response script) tab, and add:

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

pm.test("Returns post 1", () => {
    const body = pm.response.json();
    pm.expect(body.id).to.eql(1);
    pm.expect(body.title).to.be.a("string");
});

pm.test("Responds in under 1 second", () => {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

Test 2 — POST to create a resource

Create POST https://jsonplaceholder.typicode.com/posts, set the body to raw → JSON:

{ "title": "API testing", "body": "Learning Postman", "userId": 1 }

and add these tests:

pm.test("Resource created", () => {
    pm.response.to.have.status(201);
});

pm.test("Returns the new id and the data we sent", () => {
    const body = pm.response.json();
    pm.expect(body.id).to.be.a("number");
    pm.expect(body.title).to.eql("API testing");
});

JSONPlaceholder fakes the creation, so the post isn't really saved — on a real API, follow up with a GET to confirm persistence.

Next, learn environments and variables in Postman Essentials and scripting in Postman Scripting.

Authentication in API Testing

Most real APIs need credentials. The common types are Basic auth (username and password, Base64-encoded), API keys (a key in a header or query parameter), Bearer tokens / JWT (a token obtained at login and sent in the Authorization header) and OAuth 2.0 (tokens issued by an authorization server). A typical test flow logs in once, stores the token in a variable, and reuses it in every request. See API Authentication.

The Learning Path

Part 1 — API Fundamentals

Part 2 — Testing With Postman

Part 3 — Specialised Testing

Part 4 — Project & Interview Readiness

Part 5 — Hands-On Practice (Postman)

Exercises on real demo APIs such as RESTful Booker, ReqRes, FakeStore, Petstore and GoRest:

From Postman to Automation

Postman is ideal for learning and exploring. When you need a large, maintainable regression suite in a Java framework, the next step is REST Assured; with Playwright, you can also use its built-in API testing. See REST Assured vs Postman for when to switch, and the API Testing Roadmap for the full path.

How to Use This Guide

  • Beginners: read this page, then follow Parts 1 → 5 in order — concepts before tools before advanced topics.
  • Postman users: focus on Part 2 and Part 5, then security and performance.
  • Interview prep: Parts 1 and 4 — be ready to explain status codes, auth, chaining and how you'd test an endpoint.

From Real Projects

My API testing experience covers CRUD operations, HTTP methods, JSON path, and validating JSON and XML responses. On Testsigma, a platform that itself automates web, mobile and API tests, understanding requests, responses and status codes was part of understanding the product. The habit that matters most: check the status code, the response body and its structure, not just that a call succeeded. Start with the CRUD flow for one resource — create, read, update, delete — and validate every field you expect to come back.

📖 Related tutorials

Frequently Asked Questions

What is the best order to learn API testing?

API fundamentals, HTTP methods and status codes, requests and responses, authentication, then Postman, advanced topics, security, performance, and finally automation with REST Assured and interview preparation.

Do I need programming knowledge for API testing?

Not to start. Postman lets you test APIs with little code — basic JavaScript is enough for test scripts. For automation frameworks, learn Java for REST Assured or TypeScript for Playwright.

What is the difference between API testing and UI testing?

UI testing drives the application through its screens like a user. API testing calls the service layer directly, so it's faster, more stable, and can reach error cases the UI hides. Most teams use both.

What is the difference between Postman and REST Assured?

Postman is a GUI tool for manual, exploratory and collection-based testing (with Newman for CI). REST Assured is a Java library for building automated API test frameworks. See REST Assured vs Postman.

Which HTTP status codes are most important?

200, 201, 204, 400, 401, 403, 404, 409, 500 and 503 — and be able to explain 401 vs 403 and 500 vs 503.

What should an API test validate besides the status code?

The response body values, schema, headers, response time, error messages, that the data was really saved, and that authorization rules are enforced.

How do I prepare for API testing interviews?

Master fundamentals, methods and status codes; practise authentication and request chaining; be ready to design test cases for an endpoint on the spot; and prepare to explain API testing in your own project.

Keep Learning