API Testing — Beyond the UI
Every modern application has an API. When you test through the UI, you’re testing one layer. When you test the API directly, you’re testing the source of truth. Junior testers who learn this skill move significantly faster than those who don’t.
1 The Hook
A junior tester at an Auckland fintech tests the “transfer funds” feature through the UI every sprint. It takes 20 minutes per test cycle — log in, navigate, fill form, submit, verify. A senior colleague shows her how to send the same transfer as a POST request in Postman. Total time: 45 seconds. Same verification, 26× faster.
She immediately uses Postman to find a bug the UI tests missed: the API accepts negative transfer amounts. The UI prevents this with front-end validation. The API has no such check. A junior tester who knows only the UI would never have found it.
2 The Rule
The UI is a guard rail. The API is the truth. Test both — but understand that a back-end bug that the front end hides will only be found at the API layer.
3 The Analogy
The kitchen vs the menu.
Testing only through the UI is like judging a restaurant only from the menu description. The API test is walking into the kitchen. You see exactly what’s being cooked, how fresh the ingredients are, and whether the health code is being followed — regardless of how the menu describes the dish.
The menu might say “fresh crays”. The kitchen might tell a different story. The UI might say “$100.00”. The API might return 100.999.
4 Watch Me Do It — First Postman Test
Here is how to send your first API request in Postman, using a NZ business registry endpoint as the example.
- Open Postman and create a new request.
- Set the method to GET, enter the URL:
https://api.business.govt.nz/services/v5/business/{nzbn} - Add a header:
Authorization: Bearer YOUR_API_KEY - Click Send.
- Read the response.
A successful response looks like this:
{
"entityName": "Resync Consulting Limited",
"nzbn": "9429047639842",
"entityStatusCode": "20",
"entityTypeCode": "LTD",
"registrationDate": "2019-03-15"
}
What to verify in that response:
- Status code 200 (not 404, 401, 500)
entityNameis a non-empty stringnzbnmatches what you requestedentityStatusCodeis a value from the known list
Adding automated checks in Postman’s Tests tab:
pm.test("Status 200", () => pm.response.to.have.status(200));
pm.test("Entity name present", () => {
const body = pm.response.json();
pm.expect(body.entityName).to.be.a('string').and.not.empty;
});
pm.test("Response under 1 second", () => {
pm.expect(pm.response.responseTime).to.be.below(1000);
});
These three lines run automatically every time you send the request. Green tick = pass. Red cross = fail. No manual checking required.
HTTP status codes every junior must know:
| Code | Meaning | What it tells you |
|---|---|---|
| 200 | OK | Success — check the body for correctness |
| 201 | Created | Something was created (POST succeeded) |
| 400 | Bad Request | You sent wrong or malformed data |
| 401 | Unauthorised | Missing or invalid authentication |
| 403 | Forbidden | Authenticated but not allowed |
| 404 | Not Found | Resource doesn’t exist |
| 422 | Unprocessable Entity | Valid format, but fails business rules |
| 500 | Internal Server Error | Something broke on the server |
{"success": false, "error": "Account not found"}. Always read the body, not just the status code.5 When to Use It
Test at the API layer when:
- A bug is hard to reproduce through the UI
- You’re testing a new endpoint before the UI is built
- You need to test validation rules quickly (negative amounts, invalid IRD numbers, past dates)
- You want to verify exactly what data the server returns vs what the UI displays
- The UI is adding formatting or rounding that might hide a precision bug
You still test through the UI when:
- You’re verifying a user journey end-to-end
- You’re checking that the UI correctly presents the data returned by the API
- You’re testing front-end validation (it should be there, and it should not be the only validation)
6 Common Mistakes
🚫 If the UI looks right, the API must be fine
I used to think: the UI shows the correct value, so the API is returning the correct value.
Actually: the UI can format, round, or filter data before displaying it. A $10.999 value might display as $11.00. The API test sees the raw value and catches the precision bug. Always verify the raw API response, not just what the UI renders.
🚫 API testing requires coding skills
I used to think: I need to know how to code before I can test an API.
Actually: Postman lets you test APIs without writing a single line of code. You write HTTP requests and read JSON — skills you already have from reading tickets and bug reports. The Postman Tests tab uses JavaScript, but the basic assertions are copy-paste from their documentation.
🚫 A 200 response means everything worked
I used to think: green status code = passing test.
Actually: a 200 means the server understood your request and responded. It does not mean the response is correct. Always check the response body: does it contain the right data, the right format, the right values? A 200 with {"balance": -500} is a failed test.
7 Now You Try
You are testing a NZ government MyIR-style tax portal. The API endpoint POST /api/income/report accepts: ird_number, income_amount, tax_year.
Write 5 test cases for this endpoint covering: a valid submission, a missing required field, an invalid IRD number format, a negative income amount, and a future tax year. For each test case include: the inputs, the expected HTTP status code, and what you check in the response body.
8 Self-Check
Click each question to reveal the answer.
Q1: What is the difference between a 401 and a 403 HTTP status code?
401 Unauthorised means the request has no valid authentication — no token, expired token, or wrong credentials. The server doesn’t know who you are. 403 Forbidden means the server knows who you are but you don’t have permission. You’re authenticated but not authorised. A 401 is “who are you?”. A 403 is “I know who you are, and the answer is no.”
Q2: Why might a 200 response still indicate a failed test?
A 200 tells you the server understood and responded to the request. It says nothing about whether the response body is correct. An API can return 200 with {"success": false}, or with a wrong value, or with missing fields. The status code is the envelope; the response body is the letter. Always check both.
Q3: Name one bug type you can find at the API layer that UI testing alone would miss.
Any bug that the front end masks. Common examples: negative amounts (the UI has a validation rule but the API does not), raw floating-point precision errors (the UI rounds to 2 decimal places but the stored value is wrong), missing authorisation on endpoints (the UI never shows a button, but the API accepts the call anyway if you know the URL), or race conditions when two simultaneous requests are sent — something you can easily do in Postman but hard to trigger through UI clicks.
9 ISTQB Mapping
CTFL v4.0 Section 4.1 — Test analysis and design applicable to component and integration testing. API testing sits at the integration level — verifying that components communicate correctly across their interfaces.
CTAL-TA v3.1.2 Section 3.2.4 — Testing web services. REST APIs are the most common web service in NZ software teams and a standard expectation for mid-level test roles.