API Testing: A Practical Starting Point

1. The contract

Does the API behave as described? Check field names, types, required and optional values, and that changes do not break existing clients. If you have an API description, test against it; if you do not, write one down, because the act of doing so finds gaps.

2. Authentication and authorization

Authentication asks who you are; authorization asks what you may do. Check that missing, expired and malformed credentials are rejected, and then check the harder question: can one user reach another user's data? The OWASP API Security Top 10 puts broken object level authorization first for good reason. It happens when an API trusts an identifier sent by the client without checking that the caller is allowed to use it.

# Order 1042 belongs to user A. User B must not be able to read it.curl -s -o /dev/null -w "%{http_code}\n" \  -H "Authorization: Bearer $TOKEN_USER_B" \  https://api.example.com/orders/1042# Expect 403 or 404, never 200.

3. Data correctness

Business rules live here: totals, eligibility, limits, rounding, boundary values. Check them with realistic values and with the edges, such as zero, negative, maximum and just over maximum. Also check idempotency: what happens if the same request is sent twice?

4. Error handling

Test what happens when things go wrong: invalid input, missing fields, unavailable dependencies, timeouts. Look for the right status code, a useful and safe error message, and no leak of internal detail. A failure that returns a success status is the most dangerous kind.

5. Sequences and state

Some defects only appear across calls: using an item after deleting it, completing a step out of order, repeating a one-time action. Exploratory testing is valuable here, because scripts tend to follow the happy path.

1. List the endpoints and note which clients depend on each.
2. Rank them by business impact and exposure: money movement, personal data and partner-facing calls first.
3. Write checks per layer. A few contract checks for each endpoint, deeper rule and authorization checks for the highest-ranked.
4. Agree test data and environments, so results are repeatable.
5. Automate the repeatable part and keep exploratory sessions for odd sequences and abuse.

A minimal automated check in a framework such as Playwright shows the idea: assert on the content, not just the status.

import { test, expect } from "@playwright/test"; test("order total is the sum of its lines", async ({ request }) => {  const res = await request.get("/api/orders/1042", {    headers: { Authorization: "Bearer " + process.env.TOKEN_USER_A },  });  expect(res.status()).toBe(200);   const order = await res.json();  const sum = order.lines.reduce((t: number, l: { price: number; qty: number }) => t + l.price * l.qty, 0);  expect(order.total).toBe(sum);});

• —Checking only that a call returns 200.
• —Testing every endpoint shallowly and none deeply.
• —Skipping authorization because "the front end hides it".
• —Running tests against a shared environment whose data changes under them.
• —Letting the test suite drift from the API description.