Advanced API Testing Patterns

1 The Hook — Why This Matters

In 2023, a major NZ fintech company released a payment API that passed all junior-level tests: endpoints responded, status codes were correct, data was persisted. But in production, the system began losing money silently. Customers would create a payment order, pay successfully, but the webhook that notified the merchant never fired. Because of eventual consistency issues in the async notification system, some notifications were dropped.

Three days later, the company had processed $480,000 in payments but only notified merchants of $312,000. The missing notifications meant unsent invoices, unreconciled accounts, and furious customers. The root cause? No one tested the webhook delivery pattern. No one validated idempotency keys. No one checked what happened when a notification failed and was retried. The company lost $168,000 in reconciliation costs and compensation.

A senior tester would have designed the test strategy differently. Not just "does the API return 200?" but "does the entire flow — from payment to webhook to merchant reconciliation — work under real-world conditions?" That is what this page teaches.

2 The Rule — The One-Sentence Version

At the junior level, you test individual endpoints in isolation. At the senior level, you test integration patterns: how does the frontend react when the API is slow? What happens to the user's data if a webhook fails? Can two clients safely make concurrent requests? Does the system recover gracefully from network timeouts? These patterns determine whether your API works reliably in production.

3 The Analogy — Think Of It Like...

4 Watch Me Do It — Advanced Patterns

Pattern 1: Stateful API Testing (Sequence of Calls)

Real users don't make isolated API calls. They follow workflows: create an account, verify email, set up billing, then make a purchase. Each step depends on the previous step.

# Step 1: Create user account
POST /api/v1/users
{ "email": "alice@test.co.nz", "password": "Secure123" }
Response: 201 Created, returns user_id = "usr_123"

# Step 2: Verify email (using token from email, simulated)
POST /api/v1/users/usr_123/verify-email
{ "token": "verify_abc123" }
Response: 200 OK, email_verified = true

# Step 3: Set up payment method
POST /api/v1/users/usr_123/payment-methods
{ "card": "4111...", "expiry": "12/26" }
Response: 201 Created, returns payment_id = "pm_456"

# Step 4: Create order using the payment method
POST /api/v1/orders
{ "user_id": "usr_123", "payment_id": "pm_456", "items": [...] }
Response: 201 Created, order_id = "ord_789"

# Step 5: Verify the order was stored
GET /api/v1/orders/ord_789
Response: 200 OK, includes user_id=usr_123, payment_id=pm_456

The critical test here: does Step 5 see the user_id and payment_id from earlier steps? If not, data was lost between calls. Postman Collections or API test suites (Newman, pytest) let you chain calls and validate each response before moving to the next step.

Pattern 2: Contract Testing (Frontend ↔ Backend Agreement)

The frontend and backend must agree on the API contract: what fields are required, what types they are, what errors are possible. Contract tests verify this agreement without needing both teams to run at the same time.

Pattern 3: Security Testing at the API Layer

1. SQL Injection Try inserting SQL fragments into string fields: "name": "Robert'; DROP TABLE users;--". The API should escape the input or reject it with a 400 error.
2. Authentication Bypass Try requests without an API key, with an expired token, or with another user's token. The API must return 401 Unauthorized.
3. Authorization (horizontal privilege escalation) Can user A access user B's data? Try: GET /api/v1/users/user_b_id when authenticated as user A. The API should return 403 Forbidden.
4. Rate Limiting Send 100 requests in 1 second. The API should return 429 Too Many Requests. Check that rate limits are enforced per API key and reset correctly.
5. Data Exposure in Errors Trigger a 500 error. Does the error message expose internal paths, database names, or stack traces? It shouldn't.

Pattern 4: Async and Webhook Testing

Many APIs don't return results immediately. Instead, they accept the request, queue the work, and call your webhook when done. This requires a different test approach.

# Client initiates a long-running operation
POST /api/v1/reports/generate
{ "type": "monthly-transactions", "month": "2026-04" }
Response: 202 Accepted, returns request_id = "req_xyz123"

# Client polls for status (or waits for webhook)
GET /api/v1/reports/req_xyz123
Response: 200 OK
{ "status": "processing", "progress": 45 }

# Later, webhook fires when complete
POST https://client-webhook.example.com/on-report-ready
{ "request_id": "req_xyz123", "report_url": "https://..." }

# Test checklist:
# 1. Does 202 response include a request_id to track progress?
# 2. Can the client poll the status endpoint?
# 3. Does the webhook fire with the correct data?
# 4. Is the webhook idempotent (if it fires twice, client handles it)?
# 5. What happens if the webhook endpoint is down? Does the API retry?

Pattern 5: Idempotency (Handling Retries Safely)

When a network fails after you send a POST request, how do you know if it was received? Did the server crash before responding? You retry — but now you risk creating duplicate records. The solution is idempotency.

# Client sends request with idempotency-key header
POST /api/v1/payments
Headers: idempotency-key: "ik_9f8a7b6c5d4e3f"
{ "amount": 99.50, "currency": "NZD" }
Response: 201 Created, payment_id = "pay_123"

# Network fails. Client retries with the SAME idempotency-key
POST /api/v1/payments
Headers: idempotency-key: "ik_9f8a7b6c5d4e3f"
{ "amount": 99.50, "currency": "NZD" }
Response: 200 OK, payment_id = "pay_123"  # SAME payment, not a duplicate!

# Test: Verify idempotency by:
# 1. Send the same request twice with the same idempotency-key
# 2. Confirm you get back the same resource ID both times
# 3. Verify only one payment was actually charged

Pattern 6: Privacy Act 2020 Compliance (NZ Context)

If your API handles personal data (names, emails, IRD numbers, health info), you must test compliance with the NZ Privacy Act 2020.

5 Testing Patterns — Which to Use When

6 Common Mistakes — Don't Do This

7 Now You Try — Design a Webhook Test

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to architect API test strategies.

9 Interview Prep — Senior-Level Questions