How business analysts can test a developer's API in Postman

When a developer says a story is done, someone has to check that it actually does what the acceptance criteria say. For screens, that's easy: you click around. But a growing share of the work happens behind an API, where there's nothing to click.

That's where Postman comes in. It lets you send a request to an API and see exactly what comes back. Once you're comfortable with it, you can check an API change yourself in a few minutes, write sharper bug reports, and have more useful conversations with developers.

This guide walks through a simple routine you can use on any API story.

What you're actually testing

An API is a set of addresses (called endpoints) that other software can send requests to. Every request has the same few parts:

The API sends back a response with a status code (such as 200 OK or 404 Not Found), headers, and usually a JSON body.

Testing an API means sending the requests a story describes and checking that each response matches what the acceptance criteria promise.

Step 1: Turn acceptance criteria into requests

Before you open Postman, read the story and write down each behaviour as a request and an expected response. A story like this:

As a support agent, I want to look up a customer by their ID so that I can see their account status.

• Returns the customer's name, email and status
• Returns a "not found" error for an unknown ID
• Rejects requests without a valid token

becomes three checks:

That table is your test plan. It's also a great thing to paste into the story, so everyone agrees what "done" means.

Tip

Ask the developer for the endpoint details early: the base URL of the test environment, how to get a token, and an example request. Many teams keep this in Swagger or OpenAPI documentation, which Postman can import directly.

Step 2: Send the happy path first

Start with the request that should work. In Postman:

1. Click New → HTTP to open a new request tab.
2. Choose the method from the drop-down (here, GET).
3. Paste the URL.
4. If the API needs a token, open the Authorization tab, choose Bearer Token, and paste it in.
5. Click Send.

Then read the response from the top down:

• Status code, shown at the top right of the response pane. Is it the one you expected?
• Body. Are all the fields from the acceptance criteria there, with sensible values?
• Response time. Not usually in the criteria, but a simple lookup that takes several seconds is worth mentioning.

Step 3: Try to break it

The happy path proving that something works is only half the job. Most bugs hide in the cases nobody demoed. For each request, try a few variations:

• Missing data. Leave out a required field or query parameter.
• Wrong data. Send text where a number is expected, or a date in the wrong format.
• Data that doesn't exist. Use an ID that isn't in the system.
• No permission. Remove the token, or use one for a user who shouldn't have access.

A well-built API answers each of these with a 4xx status code and a message that explains the problem. If you get a 500 Internal Server Error instead, you've found a bug: the server crashed rather than handling bad input. Our guide to HTTP status codes explains what each code means.

Step 4: Save your requests in a collection

Once a request works, click Save and put it in a collection named after the story or feature. Next time the developer fixes something, you can rerun every check in seconds instead of rebuilding them.

Two habits make collections far more useful:

• Use environment variables for things that change between environments, like the base URL and token. Write the URL as {{baseUrl}}/customers/42, and switch from the test to the staging environment with one click.
• Name requests after the behaviour, not the endpoint: "Unknown customer returns 404" tells you far more than "GET customer 2".

Step 5: Add simple automatic checks

Postman can check responses for you. Open a request's Scripts tab, choose Post-response, and add a few lines:

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

pm.test("Customer has an email address", () => {
  const customer = pm.response.json();
  pm.expect(customer.email).to.be.a("string");
});

After each send, the Test Results tab shows which checks passed. You don't need to be a programmer to use these: Postman's snippets panel beside the editor inserts the most common checks for you.

Step 6: Write bug reports developers can act on

When something fails, the most helpful thing you can give a developer is the exact request and response. Include:

• The method and full URL
• Any headers or body you sent (remove real tokens and passwords first)
• The status code and response body you got
• What you expected instead, quoting the acceptance criterion

Postman makes this easy: the Code button (</>) in the right-hand sidebar turns your request into a cURL command that a developer can paste straight into their terminal to reproduce the problem.

Build the habit with practice

None of this is hard, but it only sticks once you've done it a few times. Our free exercise walks you through your first GET request step by step, with instant feedback on what to fix.