API Testing Guide for QA Engineers (2026)

API testing is QA's highest-leverage surface. A bug caught at the API layer is cheaper to fix than the same bug caught in the UI. The API is also where security and performance often break. This guide

API testing is QA's highest-leverage surface. A bug caught at the API layer is cheaper to fix than the same bug caught in the UI. The API is also where security and performance often break. This guide covers what to test, how to automate, and how to integrate with mobile/web testing.

Why API testing first

1. Cheaper — HTTP tests run in milliseconds, UI tests in seconds
2. More reliable — no locator flake, no timing issues
3. Closer to the bug — if the API returns wrong data, test it directly
4. Broader coverage — one API often serves many UI surfaces

A typical test pyramid: 70% unit, 20% API, 10% UI. For mobile backends, this holds well.

What to test

Functional correctness

• Every endpoint returns expected responses for valid inputs
• Status codes correct per convention (200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 404 Not Found, 422 Unprocessable Entity, 500 Server Error)
• Response bodies match schema
• Side effects happen (DB row created, email sent, webhook fired)

Input validation

• Required fields enforced
• Type checking (string vs number)
• Length limits (username max chars)
• Format (email, URL, phone)
• Rejection of malicious patterns (SQL injection, XSS)

Auth and authorization

• Unauthenticated request → 401
• Authenticated as wrong user → 403
• Authenticated with expired token → 401
• Authenticated with revoked token → 401

Rate limiting

• Per-IP limits enforced
• Per-user limits enforced
• 429 response with Retry-After header

Error handling

• Validation errors specific (not "invalid request")
• Server errors logged, not exposed in response
• Error responses follow consistent schema

Idempotency

• Duplicate POST requests with idempotency key → same result, no duplicate effect
• PATCH / PUT are idempotent (multiple applications same as one)

Concurrency

• Simultaneous writes to same resource handled per contract (last-write-wins or conflict)
• Read-your-own-writes consistency

Performance

• p95 latency under load (use load testing tools for this)
• Pagination present for large result sets
• Appropriate caching headers

Security

• HTTPS enforced
• CORS configured correctly
• No sensitive data in URLs
• No sensitive data in error responses
• Mass assignment prevented
• IDOR — user A cannot access user B's data

Tools

Postman / Newman

GUI for exploration, Newman for CI. Collection-based. Good for manual + some automation. Shared with developers easily.

REST Assured (Java/Kotlin)

given().auth().oauth2(token)
  .when().get("/users/me")
  .then().statusCode(200).body("email", equalTo("test@example.com"));

Pytest + requests (Python)

def test_get_user(token):
    r = requests.get(f"{BASE}/users/me", headers={"Authorization": f"Bearer {token}"})
    assert r.status_code == 200
    assert r.json()["email"] == "test@example.com"

Karate

DSL that reads cleanly, good for non-developers.

k6

Mainly load testing, but capable of functional tests too.

Playwright

Yes, Playwright does API testing:

const response = await request.get('/api/users/me', { headers: { Authorization: `Bearer ${token}` } });
expect(response.status()).toBe(200);

Schema validation

Use OpenAPI / JSON Schema to validate responses. Write schema once, run against every endpoint:

from jsonschema import validate
validate(response.json(), user_schema)

Catches drift: schema evolves, backend changes, test detects mismatch.

Contract testing

Consumer-driven contracts (Pact) verify that backend changes do not break the mobile or web clients that depend on them. Worth the investment for teams with independently-deployed services.

Test data

API tests need data. Options:

• Per-test setup/teardown — create resources in test, delete after. Slow but isolated.
• Fixture database — pre-populated test DB. Fast, but state can leak.
• Test user pool — shared accounts. Risk of race conditions; careful scoping.

Each approach has tradeoffs. For CI parallelism, per-test creation scoped to user is the cleanest.

CI integration

API tests in CI:

• Unit tests (backend) — < 30 seconds
• API tests — 2-5 minutes
• Integration (API + DB + downstream) — 5-10 minutes

Gate merges on API tests passing. Gate deploys on integration tests passing.

How SUSA handles API testing

SUSA captures APIs during exploration (mitmproxy on Android with root, Playwright response events on web). The captured APIs become a surface map:

• Endpoints
• Methods
• Request shapes
• Response shapes (inferred schema)
• Latency distribution
• Error patterns

Then the hammer_abuse scanners run against the captured APIs:

• IDOR attempts
• Auth bypass attempts
• Tampered headers / payloads
• Rate limit probes

susatest-agent test myapp.apk

Findings appear alongside UI issues. API regressions between releases (new endpoints, modified schemas, removed endpoints) are flagged via SUSA's evolution tracking.

The "test APIs first" mindset

Every UI bug has a shadow in the API. Test both. But when writing new tests, start with the API. Catch the bug at the source. UI tests verify the UI; API tests verify the logic.

Frequently asked questions

What testing tools work for small teams with no QA engineers?

A small team with no QA engineers needs tools where coverage does not depend on authoring: keep a thin scripted layer — Playwright or Cypress on the handful of revenue-critical flows, both free — and put breadth on an autonomous platform. SUSA takes a URL or APK and returns functional, API, accessibility, security and performance findings from one exploratory run, with CI-friendly output (non-zero exit codes, JUnit) and no suite to maintain; API-level assertions stay in code where engineers already live. Teams that would rather delegate the whole problem use a managed service. The sized decision, tool by tool, is in our QA tools for startups comparison.