DEV Community: Imran Al Munyeem

Create, Then Verify: Turning Postman Requests into Real Workflow Tests

Imran Al Munyeem — Mon, 31 Aug 2026 10:00:00 +0000

A DELETE endpoint that returns 204 No Content and deletes nothing will pass every single-request test you write.

The status code is right. The response time is fine. The body is empty, as specified. Your suite is green — and the record is still in the database, because the only way to know deletion worked is to ask again: a follow-up GET that must return 404.

That's the behaviour layer of API testing, and it can't be reached one request at a time. It needs chained requests — a sequence where each step feeds the next, testing the resource's whole lifecycle. In Postman the bridge between steps is one line of script. Here's the full pattern.

The bridge: capture, then reference

Everything hangs on one move — capture a value from a response, use it in the next request's URL or body.

Request 1 — POST /users (Scripts → Post-response):

pm.test("User created", () => pm.response.to.have.status(201));

const created = pm.response.json();
pm.collectionVariables.set("newUserId", created.id);

Request 2 — GET {{baseUrl}}/users/{{newUserId}}:

pm.test("Created user is retrievable", () => {
    pm.response.to.have.status(200);
    pm.expect(pm.response.json().id)
        .to.eql(pm.collectionVariables.get("newUserId"));
});

Run the collection (the Runner executes top to bottom) and the two requests are now one test: creation actually persisted.

Why pm.collectionVariables and not pm.environment? The captured ID is run-state, not configuration — it belongs to the suite, not to "staging vs production". Keeping run-state in collection scope also means the chain works no matter which environment is selected.

The full lifecycle chain

The canonical workflow folder — five requests, each verifying the last:

📁 User lifecycle
   1. POST   /users            → 201, capture newUserId
   2. GET    /users/{{newUserId}} → 200, fields match what was sent
   3. PATCH  /users/{{newUserId}} → 200, capture nothing, send {"name": "Updated"}
   4. GET    /users/{{newUserId}} → 200, name is "Updated", other fields unchanged
   5. DELETE /users/{{newUserId}} → 204
   6. GET    /users/{{newUserId}} → 404  ← the test that actually proves deletion

Step 4 deserves its subtle assertion: not just that the patched field changed, but that the others didn't — PATCH endpoints that quietly reset unrelated fields are a classic, expensive bug:

const user = pm.response.json();
pm.test("PATCH changed only the name", () => {
    pm.expect(user.name).to.eql("Updated");
    pm.expect(user.email).to.eql(pm.collectionVariables.get("originalEmail"));
});

(Capture originalEmail back in step 1, same one-liner pattern.)

Fresh data every run

A chain that creates test@example.com works exactly once against a persistent database — the second run collides with the first run's leftovers. Postman's dynamic variables fix this with zero code:

{
  "name": "{{$randomFullName}}",
  "email": "{{$randomEmail}}",
  "ref": "{{$guid}}"
}

Every run creates unique records. And the companion discipline: tests that create data should delete it — which the lifecycle chain does by design, steps 5–6. A suite that cleans up after itself is a suite you can run any time, from anywhere, including every 15 minutes from CI. Re-runnability is the cardinal virtue of automation.

Controlling the flow

By default the Runner goes top to bottom. Scripts can redirect it:

// Skip to teardown if creation failed — no point testing a ghost
if (pm.response.code !== 201) {
    pm.execution.setNextRequest("Cleanup");
}

// Or end the run entirely
pm.execution.setNextRequest(null);

(postman.setNextRequest is the legacy name; pm.execution.setNextRequest is current.) Use it sparingly — a suite that jumps around is hard to read — but skip-on-failure and polling loops are exactly what it's for.

Keep chains short

One warning from maintenance experience: chains are powerful and chains are coupling. A folder where request 6 depends on request 1 is fine; a collection where request 40 depends on request 3 is unmaintainable. The discipline that scales: each workflow folder is self-contained — it creates what it needs, verifies behaviour, and destroys what it made. Folders can run independently; requests within a folder cannot. That's the right amount of coupling.

Adapted from Chapter 7 of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing*. Read online, grab the PDF/EPUB, or contribute on GitHub.

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.

The Postman Variable Mistake That Leaks Tokens (and the 5-Scope Model That Prevents It)

Imran Al Munyeem — Mon, 24 Aug 2026 10:00:00 +0000

Every Postman environment variable has two value fields, and the difference between them is a security boundary:

Initial values sync to Postman's servers and are shared with everyone who can see the workspace. Current values stay on your machine.

The classic leak writes itself: someone pastes a Bearer token into the initial value "just for a second" to test something. It syncs. A teammate forks the collection into another workspace. Someone makes a workspace public to share a demo. The token is now indexed, shared, or both — and nobody typed a single careless character; they just used the wrong column.

Once you know the rule, prevention is trivial. So here's the rule, plus the rest of Postman's variable model — because the same five-scope system that keeps secrets safe is also what makes one collection run against staging, production, and CI without editing a single request.

The five scopes, narrowest wins

Postman resolves {{variables}} through five scopes, and the narrowest matching scope wins:

local > data > environment > collection > global

Global — exist outside any environment. Quick and dirty; fine for prototyping, wrong for anything permanent.
Collection — travel with the collection. Ideal for constants that belong to the suite itself (API version strings, fixed test-record IDs) — they work even when someone imports your collection without your environments.
Environment — the workhorses. Everything that differs between deployments: base URLs, credentials, tenant IDs.
Data — come from a CSV/JSON file during data-driven runs; each iteration reads one row.
Local — set in scripts, live for a single request or iteration, then vanish. The override-everything scope.

In scripts, each has an API — pm.environment.get("baseUrl"), pm.collectionVariables.set("userId", id), pm.globals.get(...) — plus pm.variables.get(...), which walks the precedence chain for you.

The pattern that makes suites portable

One discipline turns this from trivia into leverage: environments should differ in values, never in structure.

Create Staging and Production with identical variable names — baseUrl, token, tenantId — and different values. Every request references {{baseUrl}}; no request knows which environment exists. Switching your entire suite between deployments becomes a one-click act, and pointing CI at a third environment is a file, not a refactor.

// Requests use:   GET {{baseUrl}}/users/{{userId}}
// Scripts use:
const base = pm.environment.get("baseUrl");

If you ever find yourself editing a request to switch environments, a variable is missing.

Handling actual secrets

Four rules, in increasing order of paranoia:

1. Secrets go in current values only. Never initial. The initial value of token can be empty or a placeholder like SET-ME-LOCALLY — that placeholder syncing to teammates is a feature, because it documents what they need to supply.

2. Set the variable type to secret. It masks the value on screen — protection against shoulder-surfing, screen shares, and screenshots in bug reports.

3. For the truly sensitive, use Postman Vault. Vault values are encrypted locally and never sync at all — referenced as {{vault:my-token}}. The right home for production credentials, if they must exist in Postman at all.

4. In CI, no files carry secrets. Exported environment JSON contains values in plain text, so exported environments must be sanitised before committing. The real credential enters at runtime from the pipeline's secret store:

newman run collection.json -e Staging.postman_environment.json \
  --env-var "token=$API_TOKEN"

--env-var injects it as an environment-scoped variable for that run only — nothing on disk, nothing in the repo, masked in CI logs.

Two debugging tips that save an hour each

Orange vs red. A resolved {{variable}} renders orange in the URL bar; an unresolved one renders red. Red means a typo in the name — or, nine times out of ten, no environment selected in the dropdown.

The Console never lies. Postman's Console (in the footer) shows every request as actually sent — variables resolved, final headers. When a request "mysteriously" hits the wrong host or sends {{token}} literally, the Console ends the mystery in seconds. console.log() from your scripts lands there too.

The one-sentence version

Same names across environments, secrets in current values (or Vault), --env-var in CI — and the entire class of "it works on my machine / we leaked a token" problems disappears from your Postman practice.

Adapted from Chapter 6 of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing*. Read online, grab the PDF/EPUB, or contribute on GitHub.

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.

From Postman Collection to CI Gate: The Complete GitHub Actions Pipeline

Imran Al Munyeem — Mon, 17 Aug 2026 10:00:00 +0000

A Postman collection that runs when you click Run is a tool. The same collection running on every push — turning the build red before a broken API reaches anyone — is infrastructure.

The gap between those two states is smaller than most teams think: one exported file, one secret, and about 30 lines of YAML. Here's the complete pipeline, including the parts tutorials usually skip (secrets, reports, and what actually makes the build fail).

Step 1 — Put the collection in the repo

Export your collection ([…] → Export → Collection v2.1) and any environment, and commit them beside the code they test:

your-repo/
├── src/
├── collections/
│   └── MyCollection.postman_collection.json
├── environments/
│   └── Staging.postman_environment.json
└── .github/workflows/api-tests.yml

This is the pattern that scales: tests are versioned, reviewed in PRs, and branch with features. (One compatibility note: export v2.1, not the newer v3 YAML format — Newman can't run v3; only the official Postman CLI can.)

Strip secrets from the environment file first. Exported environments contain values in plain text. Tokens don't go in the file — they go in the pipeline's secret store, injected at runtime. That's step 3.

Step 2 — The workflow

.github/workflows/api-tests.yml:

name: API Tests
on:
  push:
  schedule:
    - cron: "0 2 * * *"   # nightly at 02:00 UTC

jobs:
  postman-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "lts/*"

      - name: Install Newman
        run: npm install -g newman newman-reporter-htmlextra

      - name: Run collection
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}
        run: >
          newman run collections/MyCollection.postman_collection.json
          -e environments/Staging.postman_environment.json
          --env-var "token=$API_TOKEN"
          -r cli,htmlextra

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-report
          path: newman/

What each piece buys you:

on: push + schedule — every code change is tested, and the nightly run catches drift in the API even on quiet days.
--env-var "token=$API_TOKEN" — the credential enters at runtime from GitHub's encrypted secrets, never touching a file or the logs.
-r cli,htmlextra — console output for the Actions log and a rich HTML report.
if: always() on the upload — you want the report especially when tests fail; without always(), a red run skips the step and eats your evidence.

Step 3 — The secret

Repo → Settings → Secrets and variables → Actions → New repository secret → name it API_TOKEN, paste the value. Reference it only via ${{ secrets.API_TOKEN }} as above. GitHub masks it in logs automatically.

In the collection, the request reads it as {{token}} — same as any Postman variable. Locally you keep the real value in the environment's current value (never synced, never exported); in CI it arrives via --env-var. One collection, two credential sources, zero leaks.

Why the build actually fails

No configuration needed: Newman exits non-zero when any test fails, and a non-zero exit code fails the Actions step, which fails the workflow, which blocks the merge if you've made the check required (Settings → Branch protection → require status checks). That exit code is the entire contract between your tests and your pipeline — the same mechanism works identically in Jenkins, GitLab CI, CircleCI, and Azure Pipelines.

The Postman CLI variant

Prefer running the live collection from your workspace instead of an exported file? Swap two steps:

      - name: Install Postman CLI
        run: curl -o- "https://dl-cli.pstmn.io/install/linux64.sh" | sh

      - name: Run collection
        env:
          POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}
        run: |
          postman login --with-api-key "$POSTMAN_API_KEY"
          postman collection run YOUR-COLLECTION-ID -e YOUR-ENVIRONMENT-ID

No exports to keep in sync, and each run posts a shareable report back into your Postman workspace. The trade-off: your CI now depends on Postman's cloud being reachable, and the "tests as code, reviewed in PRs" property weakens. Teams that treat the collection as source code tend to stay with exported files; teams that live in Postman's workspace tend to prefer the CLI. Both are legitimate.

The checklist version

Export collection (v2.1) + sanitised environment into the repo
Add the workflow file
Add the secret; wire it with --env-var
Make the check required in branch protection
Open a PR with a deliberately failing test and watch it get blocked — that's your proof the gate works

Total time, honestly: under an hour. Ongoing servers to maintain: zero.

Adapted from Chapter 13 of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing** — which also covers the full Jenkins setup if that's your shop. Read online, grab the PDF/EPUB, or contribute on GitHub.*

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.

Contract Testing in 10 Lines: JSON Schema Validation in Postman

Imran Al Munyeem — Mon, 10 Aug 2026 10:00:00 +0000

Here's a bug your test suite probably wouldn't catch.

A backend developer refactors the user model. The id field — an integer since forever — starts coming back as a string: "42" instead of 42. Every value is still "correct". Your assertion pm.expect(user.id).to.eql(42) fails, sure — but only on the one endpoint you asserted id on, not the other nine that return users. Meanwhile three client apps that did user.id + 1 are now computing "421".

That's structural drift, and it's what actually breaks API consumers: renamed fields, changed types, properties that quietly vanish. Field-by-field value assertions catch it patchily and by accident. Schema validation catches it systematically — and in Postman it costs about ten lines, because the ajv JSON-schema validator is built into the script sandbox.

The ten lines

In Scripts → Post-response on any request that returns a user:

const userSchema = {
    type: "object",
    required: ["id", "name", "email"],
    properties: {
        id:    { type: "integer" },
        name:  { type: "string" },
        email: { type: "string", pattern: "@" }
    }
};

pm.test("Response matches the user schema", () => {
    pm.expect(pm.response.json()).to.be.jsonSchema(userSchema);
});

That single test now fails if id becomes a string, if email disappears, if name becomes an object — every structural mutation, whether or not you thought to assert on that field's value.

For an endpoint returning an array of users:

const userListSchema = {
    type: "array",
    minItems: 1,
    items: userSchema   // reuse the object schema
};

pm.test("List matches schema", () => {
    pm.expect(pm.response.json()).to.be.jsonSchema(userListSchema);
});

Share one schema across every endpoint

The real power move: your API returns users from /users, /users/:id, /login, /teams/:id/members… and they should all be the same shape. Store the schema once as a collection variable (JSON, stringified), and every request validates against the same contract:

// One-time setup — e.g. in the collection's Pre-request script:
pm.collectionVariables.set("userSchema", JSON.stringify({
    type: "object",
    required: ["id", "name", "email"],
    properties: {
        id:    { type: "integer" },
        name:  { type: "string" },
        email: { type: "string", pattern: "@" }
    }
}));

// In any request's Post-response script:
const schema = JSON.parse(pm.collectionVariables.get("userSchema"));

pm.test("User matches the shared contract", () => {
    pm.expect(pm.response.json()).to.be.jsonSchema(schema);
});

Now when the contract legitimately changes — a new required field, say — you update one variable and every endpoint's test updates with it. That's contract testing: not a new tool, just the discipline of asserting shape centrally.

Schema tips that save real debugging time

required is where the protection lives. JSON Schema ignores missing properties unless they're listed in required. A schema without required validates {} happily — the most common reason people think their schema test "isn't working".

Type-check numbers deliberately. integer vs number matters — prices and quantities have different rules. And remember the drift that motivates all this is usually number→string, so never write type: ["integer", "string"] to make a flaky test pass. That's deleting the alarm.

Formats catch bad data early. pattern for emails and IDs, enum for status fields:

status: { type: "string", enum: ["active", "suspended", "deleted"] }

When someone adds a fourth status without telling anyone, you find out from a red test instead of a production incident.

Start schemas from reality, not from scratch. Send the request once, copy the response, and derive the schema from it (an LLM does this conversion well — then review it against the spec, especially which fields are truly required; a schema generated from one happy response will mark optional fields as required and miss fields that were null that day).

Where this sits in a strategy

Schema validation is one layer of a complete endpoint checklist — protocol (status, headers, timing), contract (this), data values, behaviour (state actually changed), and security (auth negatives). It's the layer with the best effort-to-protection ratio in the whole list: ten lines per shape, and an entire category of consumer-breaking regressions becomes impossible to ship silently.

Adapted from Chapter 7 of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing*. Read online, grab the PDF/EPUB, or contribute on GitHub.

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.

Still Testing APIs Like It's 2022? Here's Everything That Changed"

Imran Al Munyeem — Mon, 03 Aug 2026 10:00:00 +0000

If you learnt Postman a few years ago and have been coasting on that knowledge, an uncomfortable amount of it is now wrong — not "slightly dated" wrong, but "the tab you're looking for doesn't exist" wrong.

I know because I wrote a Postman guide in 2022 and recently rewrote it as a full book. Here's the changelog of everything that broke, moved, or appeared — the field guide I wish I'd had.

1. The Tests tab is gone

The old Tests and Pre-request Script tabs were merged into a single Scripts tab with two sections: Pre-request (runs before the request) and Post-response (runs after — this is where your tests live now).

Your code is unchanged — same pm.test, same Chai assertions, same snippets — only the geography moved:

// Exactly the same as it ever was, just under Scripts → Post-response
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Every tutorial screenshot showing a Tests tab is from the old world. The concepts transfer completely.

2. Newman has an official successor

Newman — the beloved open-source CLI runner — is no longer the only way to run collections from a terminal. The official Postman CLI authenticates with a Postman API key and can run collections straight from your workspace, no export step:

postman login --with-api-key $POSTMAN_API_KEY
postman collection run 12345678-abcd-efgh-ijkl-9876543210ab

It also pushes results back to Postman's cloud as a shareable run report.

Newman still works fine and its htmlextra HTML reports remain unmatched — but there's a hard compatibility line to know: Newman only supports collection format v2/v2.1. Postman v12 introduced a v3 (YAML) format for its Git-native workflows, and Newman cannot run it. New pipeline? Start with the Postman CLI. Existing Newman pipeline? It keeps working — just export v2.1.

3. Your Jenkins tutorial will not work

The classic "install JDK 8, run java -jar jenkins.war" instructions are dead: modern Jenkins requires Java 21 (recent LTS lines dropped Java 17 and older). If you're standing up a CI box today, grab Temurin 21 from adoptium.net first, or Jenkins simply won't start.

Better yet, notice that for many teams the Jenkins box is now optional — a 25-line GitHub Actions workflow runs your collection on every push and every night, with no server to patch:

name: API Tests
on:
  push:
  schedule:
    - cron: "0 2 * * *"
jobs:
  postman-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "lts/*"
      - run: npm install -g newman newman-reporter-htmlextra
      - run: newman run collections/MyCollection.postman_collection.json -r cli,htmlextra

4. There's an AI in the footer

Postbot generates tests from plain-English prompts, adds baseline tests to a whole collection in one action, repairs failing scripts, documents requests, and visualises responses. It's genuinely useful and genuinely dangerous in the same specific way: it writes assertions from the response your API currently gives — so if the current behaviour is a bug, the bug becomes the expected result. Generate freely; review against the spec, not the response. (I wrote a whole piece on this failure mode.)

Postman also added AI request types (test your LLM-backed endpoints like any other), Agent Mode, and an MCP server — the platform is clearly betting that agents will be first-class API consumers.

5. Your practice APIs died

Heroku ended its free tier, taking a generation of tutorial APIs with it. If a guide points you at something.herokuapp.com, expect a dead link. JSONPlaceholder (jsonplaceholder.typicode.com) remains free, signup-less, and reliable — or create a mock server inside Postman itself from your saved examples.

6. The scripting API moved on politely

postman.setNextRequest(null) still works, but the current form is:

pm.execution.setNextRequest(null);   // stop the run
pm.execution.setNextRequest("Delete user");   // or jump to a request

Same story across the pm API: old code keeps running, new code should use the new names.

7. Secrets got first-class treatment

Two things every team should know: variables now have a secret type (masked on screen), and — the one that catches people — initial values sync to Postman's servers and are shared with collaborators, while current values stay on your machine. Real credentials go in current values only, or in Postman Vault (encrypted, local, never synced). The classic leak is a Bearer token pasted into an initial value "just for a second," then synced, then forked into a public workspace.

The takeaway

None of this changed what good API testing is — five layers of assertions, negative cases, deterministic suites, CI enforcement. What changed is the tooling around it, and the tooling changed enough that 2022 muscle memory now produces broken pipelines and missing tabs. Update the muscle memory; keep the principles.

This is the story behind my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing** — a 2022 guide rewritten end-to-end for how we test now. Read online, grab the PDF/EPUB, or contribute on GitHub.*

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.

AI Writes Your API Tests Now. Here's the Bug It Introduces.

Imran Al Munyeem — Mon, 27 Jul 2026 10:00:00 +0000

Ask an AI to write tests for your API endpoint and it will do something subtly dangerous: it will look at the response your API currently gives and write assertions that lock it in.

If that response is correct — great, you just saved twenty minutes. If that response is a bug — say, your API wrongly returns 200 OK for an invalid payload — the AI will happily generate pm.test("Status code is 200", ...) and your bug is now the expected behaviour, defended by a green test forever.

That's the whole tension of AI-assisted testing in one sentence: AI-generated tests validate what a response is, not what it should be. The specification lives in your head and your docs; the AI only sees the wire.

I use AI test generation daily and I'm not telling you to avoid it — I'm telling you how to use it without it quietly rotting your suite.

What the AI is genuinely great at

Postman's built-in assistant, Postbot, is the one most API testers will meet first (the pattern applies equally to Copilot, Claude, or whatever you use). Its strongest moves:

Boilerplate generation. Open a request, send it once so a response exists, open Scripts → Post-response, and prompt in plain English:

"Add tests for the status code, the content type, and that the response time is under 500 ms."

It writes idiomatic pm.test / pm.expect code straight into the editor. For an entire collection, Generate tests from the collection menu adds baseline tests to every request at once — hours of boilerplate become minutes of review.

Fixing broken scripts. When a test throws an error, Postbot's Fix script analyses it and proposes a correction. For syntax slips and stale JSON paths, this is close to magic.

Exploration. "What's wrong with this request?", "visualise this response as a table", "document this collection" — context-aware answers that used to mean twenty minutes of reading.

Test-case brainstorming. Outside Postman, feeding an OpenAPI spec to an LLM and asking for edge cases is genuinely productive: it will suggest boundary values, weird Unicode, and state transitions you hadn't listed. Treat the output as a checklist to evaluate, not a suite to paste.

Where it fails, specifically

Three failure modes recur:

1. The observed-behaviour trap (the big one, above). Every generated assertion needs review against the spec, not the response. The question is never "does this match what came back?" — the AI already guaranteed that. The question is "is what came back correct?"

2. Happy-path bias. Ask for tests and you'll get success cases. The negative suite — wrong passwords, missing fields, expired tokens, malformed bodies, the requests an attacker sends — still needs a human's adversarial instinct. My rule of thumb: a real endpoint needs five to ten negative/boundary cases per positive case, and the AI will volunteer roughly none of them unprompted.

3. Plausible nonsense. Occasionally the generated assertion is syntactically perfect and semantically empty — checking that an array "exists" rather than that it contains the right things. A suite full of these is worse than a small honest one, because it looks like coverage.

The working protocol

What this adds up to in practice:

Learn to write tests by hand first. Not for purity — because review is the whole job now, and you cannot review code you couldn't have written. A test you can't read is a test you can't trust.
Generate, then interrogate. For each AI assertion ask: does the spec say this? If the response were wrong in the most likely way, would this catch it?
Add the negatives yourself. Budget the time you saved on boilerplate for the adversarial cases the AI skipped.
Never paste secrets into prompts. Tokens, customer data, internal URLs — they don't belong in any AI conversation unless your plan contractually protects them. (Postbot on enterprise plans excludes inputs from training; check your tier's terms.)
Own the suite. If a generated test fails six months from now, someone has to understand it in ninety seconds. That someone is you.

The honest framing

Used this way, AI does for test authoring what Newman did for test execution: it removes the drudgery and leaves you the judgement. The testers who struggle with AI are the ones who hand over the judgement too — and then wonder why their green suite missed the bug that was green by design.

Machines for repetition, humans for meaning. That division of labour was true before LLMs and it will be true after whatever comes next.

Adapted from Chapter 14 of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing** — 15 chapters from your first request to AI-assisted CI/CD pipelines. Read online, grab the PDF/EPUB, or contribute on GitHub.*

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.

How to Design an API Test Strategy (Not Just Accumulate Tests)

Imran Al Munyeem — Mon, 20 Jul 2026 10:00:00 +0000

Most API test suites are decorative.

They're green, they run on every build, and they check almost nothing that matters: a wall of status is 200 assertions over happy-path requests. When the API starts returning the wrong data, the wrong errors, or leaking internals in a stack trace, the suite stays green — because nobody ever decided what it was supposed to catch.

Tools execute tests; testers choose them. Given an endpoint, what should you actually verify? Here's the framework I use — five layers, three axes of case design, and a way to prioritise when you can't test everything first. Examples use Postman's test scripts, but the framework is tool-agnostic.

The layered checklist

For every endpoint that matters, work outside-in through five layers.

1. Protocol layer

The right status code for the right situation — and specific failures, not generic ones: 400 for malformed input, 401 for missing credentials, 403 for insufficient rights, 404 for absent resources. Plus the correct Content-Type, and a sensible response time.

pm.test("Status is 200", () => pm.response.to.have.status(200));

pm.test("Content-Type is JSON", () => {
    pm.expect(pm.response.headers.get("Content-Type"))
        .to.include("application/json");
});

pm.test("Responds within 500 ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

Cheap to write, catches an entire class of regressions. But if your suite stops here, it's decorative.

2. Contract layer

The response structure matches its schema: required fields present, types correct, formats valid. This is what protects the API's consumers — a renamed field or a number that quietly became a string breaks every client, while your value assertions may not even notice.

Postman ships the ajv JSON-schema validator, so contract testing is ten lines:

const userSchema = {
    type: "object",
    required: ["id", "name", "email"],
    properties: {
        id:    { type: "integer" },
        name:  { type: "string" },
        email: { type: "string", pattern: "@" }
    }
};

pm.test("Response matches the user schema", () => {
    pm.expect(pm.response.json()).to.be.jsonSchema(userSchema);
});

3. Data layer

The values are right: the created user has the name you sent; the filtered list contains only matching records; the total equals the sum of the parts; page 2 is actually different from page 1.

const body = pm.response.json();

pm.test("Filter returns only active users", () => {
    body.forEach(user => pm.expect(user.status).to.eql("active"));
});

4. Behaviour layer

State actually changed. After DELETE, a follow-up GET returns 404 — deletion that only claims to work is a classic bug. After PATCH, only the patched fields differ. POSTing the same order twice doesn't charge twice.

These require chaining requests — capture an ID from one response and use it in the next:

// In the POST's post-response script:
pm.test("User created", () => pm.response.to.have.status(201));
pm.collectionVariables.set("newUserId", pm.response.json().id);

// Next request: GET {{baseUrl}}/users/{{newUserId}}
// Then: DELETE, then GET again expecting 404

The behaviour layer is where the most expensive bugs live, and it's the layer happy-path suites never reach.

5. Security layer

Every negative auth case: no token (expect 401), an expired token (401), a valid token for the wrong user (403), a valid token with insufficient role (403). Plus: error responses that don't leak stack traces or internal hostnames.

Authentication isn't plumbing to get through on the way to your tests. It is a test surface — usually the highest-risk one you have.

Positive, negative, and boundary

For each input an endpoint accepts, generate cases along three axes:

Positive — valid, typical input succeeds. The case everyone writes.

Negative — invalid input fails correctly: missing required fields, wrong types, malformed JSON, unknown IDs, illegal state transitions. The assertion is not merely "it fails" but "it fails with the right status and a useful error body." An API that returns 500 for bad input has a bug even though it rejected the request — the server failed to validate.

Boundary — the edges: empty strings, zero, negative numbers, maximum lengths, page sizes of 0 and 1 and the documented limit and the limit plus one, Unicode in text fields.

A practical heuristic: for a typical endpoint, expect one or two positive cases and five to ten negative and boundary cases. If your suite is mostly green-path, it is mostly decorative.

In Postman, the clean way to industrialise this is a data file. One request, one parameterised test, a CSV of cases:

email,password,expectedStatus
valid@example.com,correct-pass,200
valid@example.com,wrong-pass,401
,correct-pass,400
not-an-email,correct-pass,400

pm.test("Status matches the data file", () => {
    pm.response.to.have.status(
        Number(pm.iterationData.get("expectedStatus"))
    );
});

Adding a case is now a spreadsheet edit — which means anyone on the team can extend coverage, not just the people who write JavaScript.

Prioritising: you cannot test everything first

Order the work by risk:

Endpoints whose failure costs most — auth, payment, anything that writes data
Endpoints that change most often — change is where regressions come from
Everything else

A ten-test suite on the login endpoint beats a hundred tests on a static reference lookup.

And adopt the single highest-value habit in test automation — the regression contract: every bug found in production earns a permanent test reproducing it. Over a year, this builds the most valuable suite you'll ever own, because it is provably aligned with how your system actually fails.

Keeping the suite honest

Three disciplines keep a growing suite trustworthy:

Deterministic tests. A test that sometimes fails without a code change is worse than no test — it trains the team to ignore red. Hunt flakiness down; it's usually shared state, missing teardown, or time-dependent assertions.

Independent tests where possible. Chained workflows are necessary, but keep chains short and self-contained. A suite where request 40 depends on request 3 is unmaintainable.

Readable failures. Name tests so a red line states the defect. "PATCH ignores read-only fields" tells the developer everything before they even open the tool. "Test 12 failed" tells them nothing.

The one-line summary

A test suite earns its keep not by the number of green ticks but by the decisions behind them: five layers per endpoint, five-to-one negative-to-positive ratio, risk-ordered, deterministic, and readable when red.

This article is adapted from Chapter 8 of my free, open-source book *API Testing Using Postman: The Practical Guide to Modern API Testing** — 15 chapters from your first request to AI-assisted CI/CD pipelines, with a 37-question interview FAQ. Read it online, grab the PDF/EPUB, or contribute on GitHub.*

I'm a PhD researcher in Computer Science at Nottingham Trent University working on cybersecurity and AI-assisted security testing. More at imranalmunyeem.com.