What Is Postman? How to Test Your AI-Built APIs Without Writing Code

Why AI Coders Need This

Here is a situation that happens constantly: you ask Claude, Cursor, or Windsurf to build you a REST API. The AI generates an Express server, a handful of routes, some database queries, and tells you the API is ready. It might even say "I've tested the endpoints and they work."

But has it? You have no idea. The server is running in your terminal. The AI says the endpoints exist. But until you actually send a request to those endpoints and see what comes back, you are taking the AI's word for it. And AI gets things wrong — missing routes, broken database connections, wrong response formats, endpoints that return 500 errors the moment you hit them with real data.

This is where Postman comes in. It is a visual tool where you type in a URL, pick an HTTP method (GET, POST, PUT, DELETE), optionally add headers or a request body, and click Send. The response shows up immediately — the status code, the headers, the JSON body, the response time. No code to write. No terminal commands to memorize. Just a clear window into what your API is actually doing.

Think of Postman like a control panel for your backend. The same way you would open a browser to test a frontend, you open Postman to test a backend. Except browsers are designed for HTML pages — Postman is designed for REST APIs that return raw data.

Real Scenario

You open Cursor and type this prompt:

Build me a REST API for managing a task list using Node.js and Express.
- Store tasks in memory (no database needed)
- Each task has: id, title, completed (boolean)
- Create endpoints for: get all tasks, create a task, update a task, delete a task
- Run on port 3000

The AI generates a file called server.js that looks something like this:

const express = require('express');
const app = express();
app.use(express.json());

let tasks = [
  { id: 1, title: 'Learn about APIs', completed: false },
  { id: 2, title: 'Test with Postman', completed: false }
];
let nextId = 3;

// GET all tasks
app.get('/api/tasks', (req, res) => {
  res.json(tasks);
});

// POST create a new task
app.post('/api/tasks', (req, res) => {
  const task = { id: nextId++, title: req.body.title, completed: false };
  tasks.push(task);
  res.status(201).json(task);
});

// PUT update a task
app.put('/api/tasks/:id', (req, res) => {
  const task = tasks.find(t => t.id === parseInt(req.params.id));
  if (!task) return res.status(404).json({ error: 'Task not found' });
  task.title = req.body.title || task.title;
  task.completed = req.body.completed ?? task.completed;
  res.json(task);
});

// DELETE a task
app.delete('/api/tasks/:id', (req, res) => {
  tasks = tasks.filter(t => t.id !== parseInt(req.params.id));
  res.status(204).send();
});

app.listen(3000, () => console.log('Server running on port 3000'));

The AI says: "Run node server.js and your API will be available at http://localhost:3000." You run it. The terminal says "Server running on port 3000." Now what? You cannot type localhost:3000/api/tasks into a browser and expect a useful experience — the browser can only do GET requests. How do you test POST, PUT, and DELETE? How do you send a JSON body?

That is exactly what Postman solves.

Getting Started with Postman

Setting up Postman takes about two minutes. Here is the process:

Step 1: Download Postman

Go to postman.com/downloads and download the desktop app for your operating system. There is also a web version, but the desktop app works better for testing localhost APIs because it runs on your machine and can reach localhost directly.

Install it and create a free account (or skip the sign-in if it lets you — older versions allowed this, newer versions require an account).

Step 2: Create your first request

Once Postman is open, you will see a workspace with a big orange "New" button or a tab area. Click the + button to create a new request tab. You will see:

• A method dropdown (defaults to GET) — this is where you pick GET, POST, PUT, DELETE, etc.
• A URL bar — where you type the endpoint address
• Tabs for Params, Authorization, Headers, Body — these are options you can set before sending
• A big blue Send button

Step 3: Send your first GET request

With your task API running locally (node server.js), type this into the URL bar:

http://localhost:3000/api/tasks

Make sure the method is set to GET. Click Send.

The bottom panel lights up with the response. You should see:

[
  {
    "id": 1,
    "title": "Learn about APIs",
    "completed": false
  },
  {
    "id": 2,
    "title": "Test with Postman",
    "completed": false
  }
]

On the right side of the response, you will see Status: 200 OK, the response time in milliseconds, and the response size. That is it — you just tested your first API endpoint. No code written, no terminal commands memorized.

Testing CRUD Operations

CRUD stands for Create, Read, Update, Delete — the four basic operations every API supports. Here is how to test each one in Postman against the task API from our scenario.

READ — GET all tasks

You already did this one. Method: GET. URL: http://localhost:3000/api/tasks. Click Send. You see an array of tasks. This is the "Read" in CRUD.

CREATE — POST a new task

This is where Postman really earns its keep, because you cannot do this in a browser.

1. Change the method dropdown to POST
2. Keep the URL as http://localhost:3000/api/tasks
3. Click the Body tab below the URL bar
4. Select raw and change the dropdown from "Text" to JSON
5. Type your request body:

{
  "title": "Deploy to production"
}

Click Send. The response should show:

{
  "id": 3,
  "title": "Deploy to production",
  "completed": false
}

Status: 201 Created. Your API received the JSON, created the task, assigned it an ID, and sent it back. If you switch back to the GET request and send it again, you will see three tasks now instead of two.

UPDATE — PUT to modify a task

1. Change the method to PUT
2. Set the URL to http://localhost:3000/api/tasks/1 (the /1 targets task with ID 1)
3. In the Body tab, select raw → JSON
4. Type:

{
  "completed": true
}

Click Send. The response shows the updated task with completed: true. Status: 200 OK.

DELETE — Remove a task

1. Change the method to DELETE
2. Set the URL to http://localhost:3000/api/tasks/2
3. No body needed — DELETE requests typically do not have one
4. Click Send

Status: 204 No Content. The server deleted the task and returned nothing — which is the correct behavior for a successful delete. Send the GET request again to confirm task 2 is gone.

Headers and Authorization

So far we have been hitting an API with no security. Real-world APIs — especially ones AI builds for production use — require authentication. You need to prove who you are before the server gives you data. Postman makes this easy.

Content-Type header

When you selected "raw" and "JSON" in the Body tab earlier, Postman automatically added a header: Content-Type: application/json. This tells the server "I am sending you JSON data." If this header is missing or wrong, the server might reject your request or fail to parse the body.

You can see and edit headers in the Headers tab. Postman shows both auto-generated headers (from your Body settings) and any custom headers you add.

Bearer token authentication

Many APIs use bearer tokens — a long string that proves you are logged in. When AI builds an API with authentication, it typically generates a login endpoint that returns a token, and then every other endpoint requires that token in the request headers.

Here is how to add a bearer token in Postman:

1. Click the Authorization tab (next to Headers)
2. Change the Type dropdown to Bearer Token
3. Paste your token into the Token field

Postman will automatically include the header Authorization: Bearer your-token-here with every request. You do not have to type the header manually.

API keys

Some APIs use API keys instead of bearer tokens. An API key is usually passed as a query parameter or a custom header. In Postman:

• As a query parameter: Add ?api_key=your-key to the URL, or use the Params tab to add it as a key-value pair
• As a header: Go to the Headers tab and add a row with the key the API expects (like X-API-Key) and your key as the value

Collections and Environments

Once you are testing more than a couple endpoints, you need a way to organize your requests and avoid typing the same values over and over. Postman handles this with collections and environments.

Collections

A collection is a folder of saved requests. Think of it like a project folder. For the task API, you might create a collection called "Task API" and save four requests inside it:

• GET All Tasks
• POST Create Task
• PUT Update Task
• DELETE Remove Task

To create a collection: click Collections in the left sidebar → New Collection → give it a name. Then save each request into that collection. Now you have a reusable test suite you can run anytime your API changes.

Environments and variables

Environments let you define variables that change depending on where your API is running. The most common example: your API runs on http://localhost:3000 during development but https://api.myapp.com in production. Instead of manually changing every URL when you switch, you create a variable.

1. Click the Environments tab in the left sidebar
2. Create a new environment called "Development"
3. Add a variable: name = base_url, value = http://localhost:3000
4. Create another environment called "Production" with base_url = https://api.myapp.com

Now in your requests, replace the base URL with {{base_url}}. Your GET request URL becomes {{base_url}}/api/tasks. Switch environments from the dropdown in the top-right corner, and every request updates automatically.

You can also store tokens and API keys as environment variables. Set a variable called auth_token and reference it as {{auth_token}} in the Authorization tab. This keeps your credentials in one place and out of shared collections.

What AI Gets Wrong

When AI builds you an API and you start testing it in Postman, you will discover that AI makes a consistent set of mistakes. Knowing these patterns up front will save you hours of head-scratching.

Wrong or missing Content-Type

AI sometimes builds API routes that expect JSON but does not add the express.json() middleware — or it adds it in the wrong place. When you send a POST request with a JSON body and the API receives undefined for the body fields, this is almost always the cause. In Postman, you can confirm the request was sent correctly by checking the Headers tab (it should show Content-Type: application/json). If Postman sent it correctly but the server still does not see the body, the problem is in the server code, not your request.

Missing auth on protected routes

AI might generate routes that require authentication middleware but forget to tell you about it. You send a request in Postman and get 401 Unauthorized or 403 Forbidden. Check the status code — if it is 401 or 403, you need to add authorization. Ask the AI: "What authentication does this endpoint require, and how do I get a token?"

Wrong request body format

AI documentation sometimes shows the request body in one format but the code expects another. For example, the AI might tell you to send {"name": "My Task"} but the actual code reads req.body.title. When you get unexpected results — a task is created but with a blank title — compare what you are sending against what the code actually reads. Postman makes this easy because you can see your exact request body right there in the interface.

Hardcoded port numbers that conflict

AI frequently hardcodes port 3000, but if another project is already running on that port, the server will crash on startup. The error message says "EADDRINUSE" which means "this port is already taken." Kill the other process or ask the AI to use a different port. In Postman, make sure the port in your URL matches whatever port the server actually started on.

Wrong HTTP methods on routes

Sometimes AI wires up a route as POST when it should be PUT, or creates a route at a slightly different path than what it documented. If Postman returns 404 Not Found and you are sure the server is running, double-check the exact method and path in the server code. A route defined as app.put('/api/tasks/:id') will return 404 if you send a POST to that same path.

Alternatives to Postman

Postman is the most popular API testing tool, but it is not the only option. Here are the main alternatives and when you might prefer them.

curl (command line)

curl is a command-line tool built into macOS and Linux (and available on Windows). It does everything Postman does but through typed commands instead of a visual interface. A simple GET request looks like:

curl http://localhost:3000/api/tasks

A POST request with a JSON body:

curl -X POST http://localhost:3000/api/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "New task"}'

curl is powerful and universal — every server in the world has it. But the syntax is hard to remember and easy to get wrong. If you are comfortable in the terminal, curl is fast. If you are not, Postman is more forgiving.

Thunder Client (VS Code extension)

If you use VS Code, Thunder Client is a lightweight API testing extension that works right inside your editor. No separate app to install. The interface is similar to Postman but simpler. It is great if you want to test API endpoints without leaving your code editor. The free version handles most individual developer needs.

Insomnia

Insomnia is a desktop app similar to Postman with a cleaner, more minimal interface. It supports REST and GraphQL testing. Some developers prefer it because it feels less cluttered than Postman, which has added a lot of features over the years. The free tier is solid for individual use.

HTTPie

HTTPie is a modern command-line tool designed to be more human-friendly than curl. The same POST request in HTTPie:

http POST localhost:3000/api/tasks title="New task"

It automatically sets JSON content type and has colorized output. If you want a command-line tool but find curl's syntax frustrating, HTTPie is a great middle ground.

What to Learn Next

Postman is your window into how APIs actually behave. Now that you know how to use it, these closely related concepts will deepen your understanding:

• What Is a REST API? — Understand the architecture behind the endpoints you are testing. REST is the pattern that defines why your API uses GET, POST, PUT, and DELETE the way it does.
• What Is CRUD? — The four operations (Create, Read, Update, Delete) map directly to what you just tested. This guide explains the concept more deeply and how it connects to databases.
• What Are HTTP Status Codes? — Every Postman response includes a status code. 200, 201, 404, 500 — they each mean something specific. Understanding them makes debugging ten times faster.
• What Is Authentication? — Once you move beyond simple APIs, every endpoint will require auth. This guide explains tokens, sessions, OAuth, and what AI usually sets up for you.
• What Is npm? — Before you can run the API that AI built, you need to install its dependencies with npm. Understanding npm completes the picture of how your AI-built project actually starts up and runs.

FAQ