Types of API Testing: 12 Types Explained with Real Examples

“API testing” is not one activity. A payment API that returns the right amount can still leak card data, crash at 2,000 users per second, or break the Android app because a field was renamed. In this lesson you will learn the 12 types of API testing used in real projects, each with a real-life scenario, a concrete test on the free SQA Tools practice API and the tools teams use for it.

The Real-Life Scenario We Will Use

The practice API mirrors this store: it has users, products, orders, login tokens, validation rules and rate limits, so every type below has a test you can actually run.

1. Smoke Testing

A tiny, fast set of checks that answers one question: is the API up and basically working after a deployment? If smoke fails, there is no point running the other 2,000 tests.

Real example: right after a release at 2 AM, a pipeline calls the health endpoint and one key read endpoint.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/health"

Checks: 200 status, "status": "ok", response time under 1 second. Tools: Postman monitor, Playwright test tagged @smoke, uptime monitors.

2. Functional Testing

Verifies that each endpoint does what the requirement says, with valid input. This is the bulk of API testing.

Real example: requirement “Filter products by category” means GET /products?category=books must return only books.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/products?category=books"

Checks: status 200; every item has category = "books"; count matches; prices are numbers; sorting works as documented.

3. Negative and Validation Testing

Sends invalid, missing, out-of-range or wrongly typed data and checks the API rejects it gracefully: correct 4xx code, useful message, no crash, no data saved.

Real example: a signup form sends an empty body. The API should list every missing field in one response, not fail with 500.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{}' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

The practice API answers 422 with three field errors (name, email, age). Other negative cases: age as a string, age 17 and 101 (boundaries), invalid email, malformed JSON (400), wrong Content-Type (415), body over 10 KB (413).

4. Integration Testing

Checks that two or more components work together correctly: API + database, service A + service B, your app + a third-party API.

Real example: when an order is placed, the order service must call the inventory service so stock drops by the ordered quantity. Test: read stock, place order, read stock again.

On the practice API, the nested resource GET /users/1/orders checks that user and order data are correctly linked: every order returned must have user_id = 1.

5. End-to-End (Workflow) Testing

Chains several API calls in the order a real user would make them, passing data from one response into the next request.

Real example: Login → search product → add to cart → place order → pay → check order status “paid”.

import { test, expect } from '@playwright/test';
const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

test('workflow: create, update, verify, delete', async ({ request }) => {
  const created = await (await request.post(`${BASE}/objects`, {
    data: { name: 'Cart #1', data: { items: 1 }, ttl: 120 },
  })).json();

  const patched = await request.patch(`${BASE}/objects/${created.id}`, { data: { data: { items: 3 } } });
  expect(patched.status()).toBe(200);
  expect((await patched.json()).version).toBe(2);

  const read = await (await request.get(`${BASE}/objects/${created.id}`)).json();
  expect(read.data.items).toBe(3);

  expect((await request.delete(`${BASE}/objects/${created.id}`)).status()).toBe(204);
  expect((await request.get(`${BASE}/objects/${created.id}`)).status()).toBe(404);
});

6. Contract Testing

Verifies that the API’s structure (field names, data types, required fields, status codes) matches the agreed contract, so consumers like the mobile app do not break.

Real example: a backend developer renames price to amount. All functional tests still pass on the backend, but the Android app shows “Rs null”. A contract test against the JSON Schema catches it in CI before release.

The practice API publishes its schema: GET /schema/user returns a JSON Schema with "additionalProperties": false. Tools: JSON Schema validators (Ajv, Zod), Pact for consumer-driven contracts, OpenAPI diff tools.

7. Security Testing

Checks authentication, authorization, data exposure, injection and abuse protection. The OWASP API Security Top 10 is the standard checklist.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/basic/profile"

8. Performance and Load Testing

Measures response time and throughput under normal and peak traffic. Related types:

• Load testing: expected peak, e.g. 500 requests/second during a sale.
• Stress testing: increase until it breaks, to find the limit and how it fails.
• Spike testing: sudden jump, e.g. traffic x10 when a flash sale opens at 12:00.
• Soak (endurance) testing: steady load for hours to find memory leaks.

Real example: Big Billion Day style sales. The product API must stay under 300 ms at the 95th percentile with 5x normal traffic.

The practice API has /delay/{seconds} to simulate slow responses and /rate-limit, which returns 429 Too Many Requests with Retry-After on the 6th call in a minute. Tools: k6, JMeter, Gatling, Artillery; Playwright for simple SLA assertions.

9. Reliability and Resilience Testing

Checks how the API and its clients behave when things go wrong: timeouts, slow dependencies, 503 responses, retries and circuit breakers.

Real example: the SMS provider is down. Does signup still complete (OTP queued for retry) or does the whole API return 500?

Practise with GET /status/503 (returns Retry-After: 10) and GET /delay/5 with a 2-second client timeout. Your client should give up cleanly and retry with back-off.

10. Regression Testing

Re-runs existing API tests after every code change to make sure nothing that used to work is now broken. This is where automation pays off: 1,000 API tests can run in a few minutes on every pull request in GitHub Actions or Jenkins.

Real example: a developer optimises the pricing query. The regression suite catches that orders with a coupon now return total 0.

11. Fuzz Testing

Sends large volumes of random, malformed or unexpected input to discover crashes and unhandled errors. Any 5xx during fuzzing is a bug.

Real example: sending a 1 MB string, emojis, null bytes, nested JSON 1,000 levels deep or numbers like 1e309 to the product search API. Tools: RESTler, Schemathesis (generates tests from OpenAPI), Burp Suite Intruder.

12. Compatibility and Versioning Testing

Ensures new API versions do not break existing clients and that old versions keep working until they are retired.

Real example: 30% of users never update the app. When /v2/orders launches, /v1/orders must keep the old response shape. Testers run the v1 suite against the new build and check deprecation headers.

Summary Table: Types of API Testing

Interview Questions: Types of API Testing