API Testing for Beginners: A Practical Guide

API testing is one of the fastest-growing skills in QA. More and more job listings require it, and for good reason — API tests are faster, more stable, and more effective than UI tests. Check out our HTTP Status Codes cheat sheet for quick reference.

This guide teaches you API testing from zero. If you're new to QA, start with the QA career roadmap first.

What is an API?

API stands for Application Programming Interface. It's how different software components communicate with each other.

When you use a website: 1. You click a button (frontend/UI) 2. The frontend sends a request to the API (backend) 3. The API processes the request and returns a response 4. The frontend displays the response

API testing skips step 1 and 4 — you send requests directly to the API and verify the responses. This is faster and more reliable than testing through the UI.

Understanding REST APIs

REST (Representational State Transfer) is the most common API style. REST APIs use standard HTTP methods to perform operations on resources.

HTTP Methods

• GET: Retrieve data (read)
• POST: Create new data
• PUT: Update entire resource
• PATCH: Update part of a resource
• DELETE: Remove data

URLs (Endpoints)

REST APIs use URLs to identify resources: - GET /users — list all users - GET /users/123 — get user with ID 123 - POST /users — create a new user - PUT /users/123 — update user 123 - DELETE /users/123 — delete user 123

HTTP Status Codes

Every API response includes a status code:

• 200 OK — request succeeded
• 201 Created — new resource created (usually after POST)
• 204 No Content — success with no response body (usually after DELETE)
• 400 Bad Request — client sent invalid data
• 401 Unauthorized — authentication required
• 403 Forbidden — authenticated but not authorized
• 404 Not Found — resource doesn't exist
• 500 Internal Server Error — something broke on the server

Memorize these — you'll use them in every API test.

Getting Started with Postman

Postman is the most popular tool for API testing. It's free and has an intuitive interface.

Your first API test

Let's test a public API. Open Postman and try:

Request: GET https://jsonplaceholder.typicode.com/users/1

Expected response: - Status: 200 OK - Body: JSON object with user data (name, email, etc.)

That's it — you just performed your first API test.

Testing CRUD Operations

Using the same API:

Create (POST): - URL: POST /posts - Body: { "title": "Test Post", "body": "Content", "userId": 1 } - Expected: 201 Created, response includes the new post with an ID

Read (GET): - URL: GET /posts/1 - Expected: 200 OK, response includes post data

Update (PUT): - URL: PUT /posts/1 - Body: { "title": "Updated Title", "body": "Updated", "userId": 1 } - Expected: 200 OK, response shows updated data

Delete (DELETE): - URL: DELETE /posts/1 - Expected: 200 OK

What to Test in APIs

1. Status codes Every endpoint should return the correct status code for both valid and invalid requests.

2. Response body Verify the response contains the expected data: - Correct structure (right fields, right types) - Correct values (data matches what was sent/stored) - No extra or missing fields

3. Error handling What happens when you send bad data? - Missing required fields → should return 400 with helpful message - Invalid data types → should return 400 - Non-existent resource → should return 404 - Unauthorized access → should return 401 or 403

4. Authentication If the API requires authentication: - Request without token → 401 - Request with invalid token → 401 - Request with expired token → 401 - Request with valid token but insufficient permissions → 403 - Request with valid token and correct permissions → 200

5. Data validation - Maximum/minimum length for string fields - Boundary values for number fields - Required vs optional fields - Email format validation - Special characters handling

6. Performance - Response time (typically under 200ms for simple endpoints) - Response size (not returning unnecessary data)

Writing Assertions in Postman

Postman lets you write JavaScript assertions in the "Tests" tab:

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

Test response body: pm.test("Response has user name", function () { const json = pm.response.json(); pm.expect(json.name).to.be.a("string"); pm.expect(json.name).to.not.be.empty; });

Test response time: pm.test("Response time under 500ms", function () { pm.expect(pm.response.responseTime).to.be.below(500); });

Organizing Tests in Collections

Postman Collections group related requests into test suites. Organize by:

• Feature (User API, Product API, Order API)
• Test type (Happy path, Error cases, Edge cases)
• Environment (Dev, Staging, Production)

Use Postman Environments to store variables (base URL, tokens) that change between environments.

API Testing in CI/CD

Postman tests can run in CI/CD using Newman (Postman's CLI):

newman run collection.json --environment staging.json

This integrates your API tests into the deployment pipeline — they run automatically on every build.

Next Steps

1. 1.Practice with public APIs (JSONPlaceholder, ReqRes, PetStore)
2. 2.Learn about authentication (Bearer tokens, OAuth, API keys)
3. 3.Study API documentation (Swagger/OpenAPI)
4. 4.Explore automated API testing frameworks (REST Assured, Supertest)
5. 5.Learn about API contract testing

API testing is one of the highest-ROI testing skills you can develop. Tests run fast, they're stable, and they catch most of the bugs that E2E tests would catch at a fraction of the cost and time.