API Testing Fundamentals

1 The Hook — Why This Matters

In 2022, a NZ health provider released a telehealth API so its mobile app could book appointments with doctors. The frontend team tested the happy path: create a patient, book an appointment, pay. It worked beautifully. Three weeks after launch, the backend API was still accepting invalid data that the frontend was supposed to reject.

A patient could create an account with no email address (field left empty in JSON). The app crashed trying to send a confirmation email. Another patient exploited a missing validation to book two appointments at the exact same time slot, causing scheduling conflicts in the clinic's database. The fix required an emergency hotfix and a $15,000 recall of test sessions.

A junior tester armed with curl and Postman would have caught both bugs before launch by testing the API directly — without relying on what the frontend told them. That is what this page teaches.

2 The Rule — The One-Sentence Version

The frontend can lie. It can validate input before sending it, reject malformed responses, or display success messages when the backend actually failed. Your job as an API tester is to verify that the API itself enforces the rules, not just the application layer. Test happy paths, error cases, missing fields, wrong data types, and edge cases directly against the API endpoint.

3 The Analogy — Think Of It Like...

4 Watch Me Do It — Step by Step

We will test a user creation API endpoint step by step using curl commands. The spec says:

POST /api/v1/users
Required fields: email, password (8+ chars), firstName, lastName
Optional: phoneNumber
Returns: 201 Created with user ID

1. Test the happy path (valid data) Send a well-formed request with all required fields. Expect a 201 status and a JSON response with the new user ID.

   curl -X POST https://api.example.co.nz/api/v1/users \
     -H "Content-Type: application/json" \
     -d '{
       "email": "alice@example.co.nz",
       "password": "SecurePass123",
       "firstName": "Alice",
       "lastName": "Smith"
     }'
   
   # Expected response (201 Created):
   # {"id": "user-12345", "email": "alice@example.co.nz", "created": "2026-04-24"}

2. Test missing required fields Send requests with each required field missing. The API must reject with a 400 Bad Request and a clear error message.

   # Missing email
   curl -X POST https://api.example.co.nz/api/v1/users \
     -H "Content-Type: application/json" \
     -d '{
       "password": "SecurePass123",
       "firstName": "Bob",
       "lastName": "Jones"
     }'
   
   # Expected response (400 Bad Request):
   # {"error": "email is required"}

3. Test invalid email format Send emails that look invalid: missing @, missing domain, spaces, special characters. The API should reject or sanitise.

   curl -X POST https://api.example.co.nz/api/v1/users \
     -H "Content-Type: application/json" \
     -d '{
       "email": "not-an-email",
       "password": "SecurePass123",
       "firstName": "Carol",
       "lastName": "Davis"
     }'
   
   # Expected: 400 Bad Request with validation error

4. Test weak passwords Send passwords shorter than 8 characters. The API must enforce the minimum length rule.

   curl -X POST https://api.example.co.nz/api/v1/users \
     -H "Content-Type: application/json" \
     -d '{
       "email": "dave@example.co.nz",
       "password": "short",
       "firstName": "Dave",
       "lastName": "Lee"
     }'
   
   # Expected (400 Bad Request):
   # {"error": "password must be at least 8 characters"}

5. Test HTTP status codes Verify every scenario returns the correct status code. 201 for success, 400 for validation errors, 409 for duplicate email (already exists), 500 for server errors.
6. Test response headers and body structure Verify the response includes Content-Type: application/json and the body is valid JSON. Check that the response matches the documented schema.
7. Test authentication (if required) Try making the request without an API key or with an invalid token. The API should return 401 Unauthorized.

5 When to Use It — The Decision Tree

6 Common Mistakes — Don't Do This

7 Now You Try — Test a User Update Endpoint

curl -X PUT https://api.example.co.nz/api/v1/users/123 \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "phoneNumber": "+64 21 555 0123"
  }'

# Expected response (200 OK):
# {"id": "123", "email": "alice@example.co.nz", "firstName": "Alice",
#  "lastName": "Smith", "phoneNumber": "+64 21 555 0123"}

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to practice.

9 Interview Prep — Know These Cold

These are questions Kiwi employers actually ask junior API testers.

10 Link to Reference

Want the full HTTP method reference, REST conventions, and authentication patterns?

11 Next Step

You now understand how APIs work and how to test them manually. The next level is learning to chain multiple API calls together: create a user, then use that user's ID to book an appointment, then verify the appointment exists. This is called stateful API testing.