How to Use Postman: The Beginner's Guide (First Request, Collections, and Your First Test)

CodexFuse Team · 2026-10-28T20:08:08.133Z · 16 min read

Learn how to use Postman from scratch: install it, send your first request, save it to a collection, add environments, write your first test, and handle auth safely.

Learning how to use Postman takes about an hour, and most of that hour is spent sending real requests, not reading theory. Postman is an API client: a tool that lets you send a request to a web address, see exactly what comes back, and save that request so you can run it again. This Postman for beginners guide walks you through the whole first-use system in order: install the app, send your first API request, save it to a collection, switch environments with variables, write your first test, and add authentication without leaking a key. If you already write code, the VS Code beginner guide pairs naturally with this one, since most developers bounce between an editor and an API client all day.

What Is Postman?

Postman is a desktop and web app for working with APIs. An API (application programming interface) is how one piece of software asks another for data or actions over the web, and Postman is the tool that lets you make that ask by hand, inspect the answer, and repeat it reliably. Instead of writing code just to check whether an endpoint works, you type a URL, pick a method such as GET or POST, press Send, and read the response in the lower pane.

That sounds simple, and the simple version is the point. Postman earns its place in a developer's day because it turns a one-off check into a saved, shareable, testable asset: a collection of requests, an environment of variables, and a set of tests that run every time the collection runs. Beginners should learn it in that order, because each layer only makes sense once the one before it works.

How Do I Install Postman and Set Up an Account?

Download Postman from the official site for Windows, macOS, or Linux, or use the web version if you cannot install software on your machine. The desktop app is the usual starting point, and Postman's own quick start guide assumes it: install the app, open it, and send your first request from a new tab.

You can use Postman without an account, but you should sign in before you do anything you care about keeping. Without an account, your work stays on that machine only; with an account, your collections and environments sync to Postman's cloud and travel with you to another computer. This is the single most common beginner loss: someone builds a useful collection while signed out, switches machines, and finds nothing there. Create the free account first, then build. One account detail matters for later: on the free plan you are the only user, so a second person cannot share your workspace for free — that line is covered in the pricing section below.

How Do I Send My First Request in Postman?

Your Postman first API request should use a safe, public endpoint that is designed for practice. Postman's own quick start uses its Echo service, which simply sends back what you sent it, so you can see the full round trip without needing any account on another service. Follow these steps exactly:

  1. Open Postman and click Add in the workbench to open a new tab.
  2. Leave the method set to GET, which means "give me this resource."
  3. Enter postman-echo.com/get as the request URL.
  4. Click Send.
  5. Read the response in the lower pane: a status, a response time, and a JSON body echoing your request back.

That round trip is the whole mental model. Postman acted as the client, the Echo server received the GET request, processed it, and returned a response, and Postman displayed that response for you. If you see a status of 200, the request worked. If you see anything else, the response pane is telling you what happened, not hiding it — learning to read that pane is the skill this guide builds.

For a second, more realistic practice request, use JSONPlaceholder, a free public practice API that many beginner guides use for exactly this purpose. Send a GET request to https://jsonplaceholder.typicode.com/posts/1 and you will get back a single fake blog post in JSON, with fields such as userId, id, title, and body. It is fake data on purpose: you can experiment freely, and nothing you send changes a real system.

What Do the Parts of a Response Mean?

Every response has four parts worth reading, in this order. First, the status code: 200 means the request succeeded, 404 means the address was not found, 401 means you are not authenticated, and 500 means something broke on the server's side. Second, the response time and size, which tell you whether the endpoint is fast or slow before you blame your own code. Third, the body, which is usually JSON data you can read in the Pretty view. Fourth, the headers, which carry metadata such as the content type and caching rules.

Beginners often stare at the body and ignore the status code. Do the opposite. A 200 with an empty body and a 404 with a helpful error message are completely different situations, and the status code is what tells you which one you are in. When a request fails, read the status first, then the body, then the headers — in that order, every time.

Which HTTP Method Should I Use?

The method is the verb of your request: it says what you want done, not just where to go. Getting this table right early prevents a whole class of confusing errors, because sending the right URL with the wrong method is one of the most common beginner mistakes.

MethodWhat it asks forBeginner example
GETRetrieve a resourceFetch one post from JSONPlaceholder
POSTCreate a resourceSubmit a new post with a JSON body
PUTReplace a resource entirelyReplace a post with a full new version
PATCHChange part of a resourceChange only a post's title
DELETERemove a resourceDelete a post by its id

Notice that GET requests carry their information in the URL, while POST, PUT, and PATCH usually carry a body. That distinction is the first thing to check whenever a request behaves unexpectedly: a body sent with a GET, or a missing body on a POST, is a frequent cause of a confusing error.

How Do I Save Requests Into a Postman Collection?

A Postman collection is a group of saved requests that you can organize into folders, run together, and share. An unsaved request is a sticky note; a collection is a filing cabinet. Postman's own quick start makes the same point: collections help you stay organized and share your work with teammates, and a collection can also hold responses, documentation, and tests.

To save your first request, click Save in the request builder, choose New Collection, give it a name such as "Practice API," and click Save again. Your new collection and its request now appear under Collections in the sidebar. From here on, build a habit: every request you send while learning should be saved into a collection with a clear name. A request named "Get post 1" is findable next week; a request named "New Request" in an unsaved tab is not.

Organize by project, not by method. A collection called "Blog API" with folders for Posts, Users, and Comments beats a collection called "GET requests" the moment your project grows, because you think in features, not verbs. Add a short description to the collection itself while the purpose is fresh in your mind — future you will not remember why a collection exists just from its request names.

How Do I Use Postman Environments and Variables?

An environment is a set of named values, called variables, that your requests can reuse. Instead of typing the same base URL into twenty requests, you store it once as a variable such as {{baseUrl}} and write every request URL as {{baseUrl}}/posts/1. When the URL changes — from a local server to a staging server, for example — you change one variable, not twenty requests.

To try this, create an environment named "Practice," add a variable called baseUrl with the value https://jsonplaceholder.typicode.com, and change your saved GET request's URL to {{baseUrl}}/posts/1. Send it again. If it still returns the same post, variables are working. Then create a second environment with a different base URL and switch between them from the environment dropdown: the same collection, two targets, zero editing.

Variables are also the safe place for secrets, which brings us to the rule that matters most in this section: never paste a real API key or token directly into a request URL, a header, or a shared collection. Put it in a variable, keep the variable's current value out of anything you export or share, and use Postman's Local Vault for values that should never leave your machine. A key pasted into a shared collection is a key you have already given away.

How Do I Write My First Postman Test Script?

A Postman test script is a small piece of JavaScript that checks the response automatically. Instead of eyeballing every response, you state what "correct" looks like once, and Postman checks it every time the request runs. Postman's own quick start uses the simplest useful test: confirming the status code is 200.

To write it, open your request, click the Scripts tab, then click Post-response. From Snippets at the lower right of the code editor, select "Status code: Code is 200." Postman inserts this code:

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

Click Send, then click Test Results in the response section. A passing test appears there, and a failing one tells you exactly which check failed. That feedback loop is the point: a test turns "I think it worked" into "Postman verified it worked, and it will verify it again next time."

From there, add one check at a time. Test that the body contains the field you need, that a list is not empty, or that a response arrives within a time limit you choose. Keep each test to one claim: a test named "Status code is 200" that also checks five other things is five tests hiding in one name, and its failure message will not tell you which claim broke.

How Do I Test POST, PUT, PATCH, and DELETE Requests?

Testing a write request means sending a body, not just a URL. In Postman, choose POST, enter https://jsonplaceholder.typicode.com/posts, open the Body tab, select raw and then JSON, and enter a small object such as a title, a body, and a userId. Click Send, and you will receive a response containing the new post with an assigned id.

Treat that response honestly. JSONPlaceholder is a practice API: it returns what a real API would return, but it does not store your post as a real record. That is a feature for learning, not a flaw — you get to practice the full create-and-read cycle without any risk. When you move to a real API, the same steps apply, except the response now has real consequences, so check the API's own docs before sending a DELETE or a PUT against anything you care about.

A useful first-week exercise is to run the full cycle on the practice API: GET a post, POST a new one, PATCH its title, then DELETE it, saving each request into your collection as you go. If all four work, you understand the method table from the earlier section in your hands, not just on paper. If one fails, the status code and body will tell you which step's assumption was wrong.

How Do I Add Authentication Without Leaking a Key?

Most real APIs require authentication: proof that you are allowed to ask. Postman handles the common methods through the Authorization tab, so you do not have to hand-build headers. The two patterns beginners meet first are API keys and Bearer tokens.

For an API key, choose API Key in the Authorization tab, add the key name the API's docs specify (often something like X-API-Key), and put the value in a variable rather than typing it directly. For a Bearer token, choose Bearer Token and paste the token into the token field, again via a variable where possible. Postman then sends the right header with every request in that collection, and you never have to remember the header format.

Three rules keep this safe. First, never use a real production key while learning — use a test key, a sandbox account, or a practice API. Second, never paste a key into a screenshot, a shared collection export, or a public workspace. Third, if a key ever does leak, revoke it at the provider immediately and issue a new one; deleting the message or the screenshot does not un-share the key. Postman's Local Vault exists for exactly this reason: values stored there stay on your machine and are not synced or exported with the collection.

Postman vs curl: When Should I Use Each?

curl is a command-line tool that sends requests from a terminal; Postman is a visual client that saves, organizes, and tests them. For a single quick check on a server, curl is often faster: one command, one response, no app to open. For anything you will repeat, share, or test, Postman wins: saved collections, environments, variables, test scripts, and a readable response viewer beat retyping commands and re-reading raw terminal output.

Most developers use both, and that is the right answer. Use curl when you are already in a terminal and need one answer fast. Use Postman when the request matters enough to keep — when a teammate will run it, when it needs a test, or when you are exploring an API you do not know yet. Learning Postman does not mean abandoning curl, and knowing curl does not make Postman redundant.

When Should I Pay for Postman?

Start free and pay only when a specific limit blocks real work. Postman's own pricing page, checked on October 28, 2026, lists four plans: Free at $0, Solo at $9 per month billed annually, Team at $19 per user per month billed annually, and Enterprise priced through sales. The free plan includes one user, 50 Postman AI credits per month, 1,000 API monitoring requests per month, 10,000 calls to the Postman API per month, up to 5 integrations, and 1 day of collection recovery.

PlanPrice (checked October 28, 2026)Who it fits
Free$0, 1 userSolo learning, personal projects, first collections
Solo$9 per month, billed annually, 1 userA solo developer who needs longer recovery and more AI credits
Team$19 per user per month, billed annuallyTeams sharing workspaces, roles, and private workspaces
EnterpriseContact salesLarge organizations needing SSO, governance, and audit logs

The practical line is the user count. The free and Solo plans each include one user, so the moment a second person needs to share your workspace, you are looking at Team pricing. Everything a beginner does in this guide — requests, collections, environments, tests, and the Collection Runner — works on the free plan, so do not pay until you hit a limit you can name, such as monitoring volume or the need for a shared team workspace. Prices change, so re-check the pricing page before budgeting around any figure here.

What Are the Common First-Week Mistakes?

Most beginner Postman problems are not Postman problems; they are small setup slips that look mysterious until you have seen them once. This table collects the ones that cost beginners the most time.

MistakeWhat you seeThe fix
Working signed outWork vanishes on another machineSign in before building anything you want to keep
Unsaved requestsUseful requests lost among new tabsSave every keeper into a named collection immediately
Wrong method, right URL405 or a confusing error on a known addressCheck the method against the API docs first
Real key in a shared exportA secret that cannot be un-sharedUse variables and the Local Vault; revoke leaked keys at once
Reading only the bodyConfusion when a failure looks like successRead the status code first, then the body
Practicing on a real APIAccidental changes to real dataLearn on Echo and JSONPlaceholder; use test keys elsewhere

If you are stuck on a request that "should work," run through that table top to bottom before searching for a deeper cause. Nine times out of ten, the answer is one of those six rows. For a broader developer workflow, the GitHub beginner guide covers the version-control side of the same projects, and the Google Jules beginner guide covers the AI-coding-assistant side. When your practice data arrives as a spreadsheet instead of an API, the CSV to Excel guide covers keeping that data intact.

Sources

Postman Docs, "Postman quick start" (learning.postman.com/docs/getting-started/quick-start/) — first-request steps with the Postman Echo API, saving a request to a collection, and the status-code-200 test snippet, fetched October 28, 2026. Postman, "Plans & Pricing" (postman.com/pricing) — Free, Solo, Team, and Enterprise prices and limits, fetched October 28, 2026. Vocal Media, "Getting Started with Postman: A Beginner's Guide to API Testing" — account-optional setup, workspace and collection concepts, and the JSONPlaceholder first-GET example, fetched October 28, 2026. Hostcoder, "Beginner's Guide to Postman" and "Your First Collection and Request" — account-optional note, workspace layout, and collection-first workflow, fetched October 28, 2026. Velog, "Postman Tutorial: A Beginner's Guide to API Testing" — JSONPlaceholder POST example with a JSON body and the returned assigned id, fetched October 28, 2026.

Frequently Asked Questions

Is Postman free for beginners?

Yes. Postman's free plan costs $0 and includes requests, collections, environments, tests, and the Collection Runner, with one user. You only need a paid plan when you hit a specific limit, such as sharing a workspace with a second person or needing more monitoring requests.

Do I need an account to use Postman?

No, you can use Postman without an account, but your work will not sync. Sign in before building anything you want to keep, so your collections and environments travel with you to another machine.

What is the best first API to practice with in Postman?

Start with Postman's own Echo service at postman-echo.com/get, which echoes your request back so you can see the full round trip. Then move to JSONPlaceholder for realistic GET and POST practice with fake data that cannot harm a real system.

What is the difference between a collection and an environment in Postman?

A collection is a saved group of requests, organized into folders. An environment is a set of variables, such as a base URL or a token, that those requests can reuse. Collections hold what you send; environments hold the values that change between targets.

Can I use Postman instead of curl?

For repeated, saved, or tested work, yes — Postman's collections, variables, and test scripts beat retyping terminal commands. For a single quick check from a terminal, curl is often faster. Most developers use both, choosing by whether the request is worth keeping.