How to Write API Test Cases: Template, Examples and 50+ Scenarios

“Write test cases for this API” is both a daily task and a favourite interview exercise. Most beginners write five happy-path cases and stop. Experienced testers use a repeatable method that produces 30 to 50 meaningful cases for a single endpoint in under an hour. In this lesson you’ll get a ready-to-use API test case template, the five test design techniques that generate cases systematically, and a complete worked example on a real endpoint you can execute right away.

Where API Test Cases Come From

Before writing a single case, collect the inputs:

• API specification (OpenAPI/Swagger, WSDL, Postman docs): endpoints, fields, types, required flags, status codes.
• Business requirements / user stories: rules like “age must be 18 to 100”, “only admins can delete”.
• Acceptance criteria and conversations with developers and product owners.
• Existing bugs and production incidents: past failures tell you where to look.

The API Test Case Template

Keep this in a spreadsheet, a test management tool (Jira Xray, Zephyr, TestRail) or directly as a Postman collection where each request is a case and its scripts are the expected results.

5 Techniques That Generate API Test Cases

1. Equivalence Partitioning (EP)

Group inputs that should behave the same and test one value per group. For role with allowed values admin/editor/viewer: valid partition {admin}, invalid partitions {unknown value “manager”}, {wrong type 5}, {empty “”}, {null}.

2. Boundary Value Analysis (BVA)

Bugs cluster at the edges. For a range min..max test min-1, min, max, max+1 (and optionally min+1, max-1).

3. Decision Tables

For rules that combine conditions. Example: delete an object on /token/objects.

4. State Transition

Resources have lifecycles. An object: does not exist → created (v1) → updated (v2, v3…) → deleted or expired. Test valid transitions and invalid ones: update after delete (404), delete twice (404), read after TTL expiry (404), update with a stale version (412).

5. Error Guessing (Experience Checklist)

Empty body, malformed JSON, wrong Content-Type, very long strings, Unicode and emojis, leading/trailing spaces, duplicate requests, special characters, SQL/HTML strings, numbers as strings, nulls, extra fields, huge numbers, negative numbers, decimals where integers expected.

Worked Example: Test Cases for POST /objects

Specification (from the practice API docs): name required, 1 to 100 characters; data any JSON up to 5 KB; ttl 10 to 1800 seconds, default 600; other fields → 422; success → 201 with Location and ETag; body over 10 KB → 413.

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Test case demo","data":{"qty":2},"ttl":60}' \
  "https://sqatools.in/wp-json/sqa-api/v1/objects"

28 cases from one endpoint, and every one of them is concrete and runnable. The practice page has 141 more, grouped exactly like this: API Testing Practice scenarios.

The Generic Checklist for Any Endpoint

Prioritising: You Can’t Run Everything Every Time

• P1 (smoke/critical): main happy paths, auth works, money calculations. Run on every deployment.
• P2 (regression): validation, roles, state transitions. Run on every build/nightly.
• P3 (extended): rare edge cases, large data, Unicode. Run before releases.

Risk-based rule: anything touching money, personal data, permissions or irreversible actions gets higher priority.

Writing Good Test Case Titles

Format: [Method] [endpoint] [expected outcome] when/for [condition]. Strong titles become readable automated test names too.

From Test Cases to Automation

A well-written table converts directly into data-driven Playwright tests: each row becomes an object, and one loop runs them all.

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

const cases = [
  { id: 'TC_10', title: 'ttl 9 is rejected',    body: { name: 'A', ttl: 9 },    status: 422 },
  { id: 'TC_11', title: 'ttl 10 is accepted',   body: { name: 'A', ttl: 10 },   status: 201 },
  { id: 'TC_12', title: 'ttl 1800 is accepted', body: { name: 'A', ttl: 1800 }, status: 201 },
  { id: 'TC_13', title: 'ttl 1801 is rejected', body: { name: 'A', ttl: 1801 }, status: 422 },
  { id: 'TC_05', title: 'name is required',     body: { data: {} },             status: 422 },
  { id: 'TC_15', title: 'client id is refused', body: { id: 'x', name: 'A' },   status: 422 },
];

for (const c of cases) {
  test(`${c.id} POST /objects: ${c.title}`, async ({ request }) => {
    const res = await request.post(`${BASE}/objects`, { data: c.body });
    expect(res.status()).toBe(c.status);
  });
}

Common Mistakes in API Test Design

• Only positive cases. Aim for more negative than positive.
• “Expected: error” instead of the exact status and message.
• Not verifying side effects (was it saved? was nothing saved on failure?).
• Test cases that depend on each other’s data and order.
• Ignoring headers and response time.
• Copying the developer’s unit tests instead of thinking like a user and an attacker.

Interview Questions: API Test Cases