API Testing Notes

01

What is an API?

An API (Application Programming Interface) is a contract that lets two systems talk to each other. In web apps the frontend sends HTTP requests; the server processes them and returns a structured response.

Client / Browser

→

HTTP Request

→

Server

→

Database

→

HTTP Response

→

Client

Three API styles you'll encounter in interviews:

REST

Uses HTTP verbs (GET, POST …). Returns JSON. Most common — what you'll test 95 % of the time.

SOAP

Older protocol. Uses XML + WSDL. Strict envelope structure. Still found in banking/enterprise apps.

GraphQL

Client specifies exactly which fields it needs. Single endpoint. Avoids over- or under-fetching.

💡

Interview tip: API testing skips the UI and hits the backend directly — it's faster, more stable, and catches bugs earlier than UI testing.

02

HTTP Methods

Every REST request uses a verb that tells the server what action to perform. Memorise these — they appear in almost every API interview.

Method	Purpose	Has Body?	Idempotent?
GET	Retrieve / read data. Never changes server state.	No	Yes
POST	Create a new resource. Each call may create another record.	Yes	No
PUT	Replace the entire resource. Missing fields become null.	Yes	Yes
PATCH	Update partial fields only. Other fields stay untouched.	Yes	Depends
DELETE	Remove a resource permanently.	Optional	Yes

📎

Idempotent means calling the same request multiple times produces the same result. GET, PUT, DELETE are idempotent. POST is not — sending it twice may create two records.

HTTP Examples

-- Read all users
GET    /users

-- Read one user
GET    /users/42

-- Create a user
POST   /users          Body: { "name": "Akash", "email": "akash@mail.com" }

-- Replace the full user record
PUT    /users/42       Body: { "name": "Akash S", "email": "new@mail.com" }

-- Update only the email
PATCH  /users/42       Body: { "email": "new@mail.com" }

-- Delete the user
DELETE /users/42

03

HTTP Status Codes

Every API response includes a 3-digit status code. The first digit tells you the category. Know these cold — interviewers love asking about them.

Code	Meaning	When you see it
200 OK	Success	GET / PUT / PATCH returned data correctly.
201 Created	Resource created	POST successfully created a new record.
204 No Content	Success, no body	DELETE succeeded; nothing to return.
301 Moved Permanently	URL changed	Endpoint has a new permanent address.
304 Not Modified	Cache hit	Client's cached version is still valid.
400 Bad Request	Invalid input	Missing required field, wrong data type, malformed JSON.
401 Unauthorized	Not authenticated	Token missing or expired. Login required.
403 Forbidden	Not authorized	Authenticated but no permission for this action.
404 Not Found	Resource missing	Wrong ID or endpoint doesn't exist.
405 Method Not Allowed	Wrong HTTP verb	Sending POST to a GET-only endpoint.
409 Conflict	Duplicate / conflict	Creating a user with an email that already exists.
422 Unprocessable	Validation failed	JSON is valid but business rules rejected the value.
500 Internal Server Error	Server crashed	Bug in backend code; check server logs.
502 Bad Gateway	Proxy error	Server got a bad response from upstream service.
503 Service Unavailable	Server down	Overloaded or under maintenance.

⚠️

401 vs 403: 401 = you haven't logged in. 403 = you're logged in but don't have permission. This distinction is a very common interview question.

04

Request Anatomy

Every API request is made up of these five parts. Know what goes where before you open Postman.

Endpoint (URL)

The full address of the resource. Includes base URL + path.

Method

GET / POST / PUT / PATCH / DELETE — the action to perform.

Headers

Metadata about the request: content type, auth token, language, etc.

Body

Data sent to the server (JSON). Used with POST, PUT, PATCH only.

Params

Query params (?key=val) or path params (/users/42) to filter or identify.

Request — Full Example

-- Endpoint
POST https://api.example.com/users

-- Headers
Content-Type:  application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Accept:        application/json

-- Body (JSON)
{
  "name":  "Akash",
  "email": "akash@mail.com",
  "role":  "tester"
}

-- Query parameter example
GET /users?city=Delhi&limit=10

-- Path parameter example
GET /users/42          ← 42 is the path parameter

💡

Query vs Path param: Use a path param to identify a specific resource (/users/42). Use a query param to filter a list (/users?city=Delhi).

05

Response Anatomy

Validate all three parts of the response — not just the body. Many bugs hide in status codes and headers.

Response — Full Example

-- Status line
HTTP/1.1 201 Created

-- Response headers
Content-Type:  application/json
Location:     /users/101
X-Request-Id: abc-123-xyz

-- Response body
{
  "id":        101,
  "name":     "Akash",
  "email":    "akash@mail.com",
  "createdAt":"2025-06-01T10:30:00Z"
}

Always check these response elements during testing:

✓ Status code is correct ✓ All expected fields present ✓ Correct data types (string, int, bool) ✓ Response time < 2s ✓ No sensitive data leaked ✓ Content-Type is application/json

06

Authentication

Most APIs are protected. You must prove who you are before the server responds with data. Here are the three types you'll encounter:

Type	How it works	Where used
API Key	A static token sent as a query param or header.	Public APIs, simple integrations.
Basic Auth	username:password encoded as Base64 in Authorization header.	Internal tools, legacy APIs.
Bearer Token (JWT)	Login → get token → send token with every request.	Most modern REST APIs.
OAuth 2.0	Third-party login (Google, GitHub). Returns access token after user consent.	Social login, cloud APIs.

Auth Header Examples

-- API Key (as header)
x-api-key: abc123xyz

-- API Key (as query param)
GET /data?api_key=abc123xyz

-- Basic Auth (Base64 encoded)
Authorization: Basic dXNlcjpwYXNzd29yZA==

-- Bearer Token (JWT)
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

📌

JWT (JSON Web Token) has three parts separated by dots: Header.Payload.Signature. The payload contains user info (id, role). It is Base64 encoded — not encrypted. Never store sensitive data in it.

Auth test scenarios to always check:

Missing token → 401 Expired token → 401 Wrong role → 403 Tampered token → 401 Valid token → 200

07

What to Test in API Testing

A complete API test covers more than just the happy path. Here are the six areas every QA engineer checks:

1 — Functional Testing

correct status code correct response body correct fields & types data is saved in DB

2 — Negative Testing

wrong credentials missing required fields invalid data types non-existent ID (404)

3 — Boundary / Edge Cases

empty string null values very long strings special characters max/min numbers

4 — Security Testing

SQL injection in params XSS in body fields access other user's data sensitive data in response

5 — Performance Testing

response time < 2s load: concurrent users stress: API breaking point

6 — Data Validation

email format valid date format correct numbers within range boolean not a string

08

Test Case Design

Always structure your test cases as: Input → Expected Output. Below is a complete example for a Login API.

Login API — POST /auth/login

Scenario	Input	Expected Result
Valid credentials	correct email + password	200 OK · token returned
Wrong password	correct email + wrong password	401 Unauthorized
Non-existent user	email not in database	404 / 401
Empty email	email: ""	400 Bad Request
Empty password	password: ""	400 Bad Request
Both fields empty	email: "", password: ""	400 Bad Request
SQL injection in email	' OR '1'='1	400 / sanitised safely
Very long password	1000-char string	400 / no server crash
Token not returned on success	correct credentials	token field must exist

📌

For any CRUD endpoint follow this test order: Create → Read → Update → Delete → Read again to confirm the final state is correct.

09

Using Postman

Postman is the most popular manual API testing tool. These are the features you should know for interviews and real projects.

Collections

Group related API requests together. Share with your team or import from a URL.

Environments

Store variables per environment (dev, staging, prod). Switch without changing URLs manually.

Variables

{{base_url}}, {{token}}. Set once, use everywhere. Avoids hard-coding values.

Pre-request Script

JavaScript that runs before the request. Useful for generating timestamps or signing payloads.

Tests Tab

Write assertions in JavaScript. Run automatically after each request.

Newman

Run Postman collections from the command line. Plug into CI/CD pipelines.

Postman — Test Scripts (JavaScript)

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

// 2. Check a field exists in the body
pm.test("Response has token", () => {
  const body = pm.response.json();
  pm.expect(body.token).to.exist;
});

// 3. Save token for next request
const body = pm.response.json();
pm.environment.set("auth_token", body.token);

// 4. Check response time
pm.test("Response under 2s", () => {
  pm.expect(pm.response.responseTime).to.be.below(2000);
});

💡

Use environment variables to chain requests — e.g. save the token from a Login response and automatically inject it into every subsequent request's Authorization header.

10

Common API Bugs

These are the defects QA engineers most commonly catch during API testing. Report them with endpoint, payload, actual result, and expected result.

Bug	Example
Wrong status code	DELETE returns 200 instead of 204. POST returns 200 instead of 201.
Missing fields in response	User object missing `email` or `id` field.
Wrong data type	`age` returned as a string `"25"` instead of integer `25`.
No validation on input	API accepts negative age, invalid email, or empty required fields.
Sensitive data exposed	Password hash or internal DB ID returned in response.
CORS misconfiguration	Browser blocks the API call because the server allows wrong origins.
No error message	400 returned with empty body — no explanation of what went wrong.
Slow response time	Simple GET takes 8 seconds — likely missing DB index.
Broken pagination	Page 2 returns the same data as page 1.
Race condition	Two simultaneous POSTs create duplicate records.

11

API Testing vs UI Testing

Interviewers often ask why API testing is preferred over UI testing. Know the trade-offs.

Factor	API Testing	UI Testing
Speed	Very fast (ms)	Slow (seconds per action)
Stability	Highly stable	Brittle — breaks on UI changes
Maintenance	Low	High — selectors break often
Coverage	Backend logic & data	User-facing flows & visuals
Bug detection	Earlier in dev cycle	Later — after UI is built
Auth testing	Easy — pass token directly	Must simulate login flow
Tools	Postman, RestAssured, Pytest	Selenium, Cypress, Playwright

📌

Best practice: 70% API tests + 20% UI tests + 10% unit tests (the testing trophy). API tests give the highest ROI per test written.

12

Interview Q&A

These are the most frequently asked API testing questions in QA / manual tester interviews. Read these the night before.

❓

What is the difference between GET and POST?
GET retrieves data and has no body. POST sends data in the body to create a resource. GET is idempotent; POST is not.

❓

What is the difference between PUT and PATCH?
PUT replaces the entire resource — missing fields become null. PATCH updates only the fields you send; everything else stays the same.

❓

What is the difference between 401 and 403?
401 = you are not authenticated (token missing or expired). 403 = you are authenticated but do not have permission.

❓

What is a REST API?
An API that follows REST principles: stateless, uses HTTP methods (GET/POST/PUT/DELETE), communicates with JSON, and identifies resources via URLs.

❓

What do you validate in an API response?
Status code, response body fields and data types, response time, headers (Content-Type), error messages on failure, and no sensitive data leakage.

❓

What is idempotency?
Making the same request multiple times produces the same result. GET, PUT, DELETE are idempotent. POST is not — calling it twice may create two records.

❓

How do you test a Login API?
Test valid credentials (200 + token), wrong password (401), empty fields (400), non-existent user (401/404), SQL injection in email field, and expired token on a subsequent request.

❓

What is the difference between query and path parameters?
Path params identify a specific resource: /users/42. Query params filter or sort a collection: /users?city=Delhi.

❓

What is Bearer Token / JWT?
A token returned after login. Sent in the Authorization header as Bearer <token>. Contains encoded user info (id, role, expiry). Must be sent with every protected request.

❓

What is the difference between SOAP and REST?
REST uses HTTP + JSON and is lightweight and flexible. SOAP uses XML with a strict envelope structure and a WSDL contract. REST is far more common in modern apps.

❓

How do you handle authentication in Postman?
Log in via POST request, save the token to an environment variable in the Tests tab, then use {{auth_token}} in the Authorization header of all subsequent requests.

❓

What is a 500 error and what do you do?
500 Internal Server Error means the backend crashed. Report it with the full request payload, check server logs if accessible, and raise it as a blocker bug because it is a backend defect.

API Testing — Quick Reference

What is an API?

HTTP Methods

HTTP Status Codes

Request Anatomy

Response Anatomy

Authentication

What to Test in API Testing

Test Case Design

Using Postman

Common API Bugs

API Testing vs UI Testing

Interview Q&A