A hands-on guide for beginners — install Postman, send HTTP requests, understand status codes, and practice on safe sandbox APIs without touching production secrets.
An API (Application Programming Interface) lets software systems talk to each other over HTTP. When you open a weather app, your phone calls a weather API. When you submit a contact form, the browser sends a POST request to a messages API. API testing means sending those requests deliberately — with different methods, headers, and bodies — to confirm the server responds correctly.
Postman is one of the most popular tools for this because you do not need to write code first. You pick a method (GET, POST, PUT, DELETE), enter a URL, add headers or a JSON body, and click Send. The response panel shows the status code, headers, and body so you can learn how REST APIs behave in the real world.
Complete these five steps in order. Each builds on the previous one and uses sandbox APIs before touching any production endpoint.
Send GET https://elangodev.com/api/test/hello and expect HTTP 200 with success: true. Jump to example →
Create a demo user at POST /api/test/user. Try omitting email once to see a 400 response. Jump to example →
Update the same user with PUT, then delete with DELETE ?id=demo-user-1. Jump to example →
Call GET /api/test/auth with Authorization: Bearer demo-token, then without it to compare 401. Jump to example →
Fetch blog JSON with Accept: application/json, or POST a test contact message with fake data. Jump to example →
Pick your operating system below. All links point to official Postman download and documentation pages.
Windows 10 or 11 (64-bit)
Tip: If SmartScreen blocks the installer, choose More info → Run anyway. The file is published by Postman, Inc.
Apple Silicon (M1/M2/M3) or Intel Mac
Tip: On Apple Silicon Macs, pick the Apple chip download for best performance and battery life.
Ubuntu 20.04, 22.04, 24.04 LTS
Terminal commands
sudo snap install postman
Tip: If snap is unavailable, use the manual Linux install steps in the Linux section below.
Fedora, Debian, Arch, and other distributions
Terminal commands
# Snap install (if snapd is installed) sudo snap install postman # Manual install from official .tar.gz cd ~ wget -O postman.tar.gz 'https://dl.pstmn.io/download/latest/linux64' sudo tar -xzf postman.tar.gz -C /opt sudo ln -sf /opt/Postman/Postman /usr/local/bin/postman postman
Tip: Flatpak and distro-specific packages exist unofficially — the Snap or official .tar.gz from postman.com/downloads are the supported options.
Follow these steps in order. By step four you will have sent your first successful API request.
GET requests fetch data without changing anything on the server. They typically have no body. Example: GET /api/test/hello returns a greeting JSON object.
POST sends data to the server, usually as JSON in the request body. Example: POST /api/test/user with name and email creates a sample user response.
PUT replaces or updates an existing resource. Use the same JSON fields as POST. Example: PUT /api/test/user updates the demo user record.
DELETE removes a resource. It often uses query parameters instead of a body. Example: DELETE /api/test/user?id=demo-user-1.
Headers carry metadata. Content-Type: application/json tells the server your body is JSON. Authorization: Bearer demo-token sends an access token for protected routes.
JSON uses double-quoted keys and string values. In Postman, choose Body → raw → JSON. Invalid JSON (trailing commas, single quotes) causes 400 errors.
Many APIs require proof that you are allowed to access them. The most common pattern for learning is a Bearer token in the Authorization header. The server reads the header, validates the token, and returns 200 if valid or 401 if not.
Authorization header (demo only)
Authorization: Bearer demo-token
Security note: demo-token is a public sample for this tutorial only. Never publish real API keys, admin tokens, or database credentials in documentation, screenshots, or GitHub repos.
Try it: GET /api/test/auth with and without the header to see success vs 401.
The status code is the first signal of success or failure. Always check it before reading the JSON body.
The request succeeded. The response body usually contains the data you asked for.
Example: GET /api/test/hello returns 200 with a greeting message.
A new resource was created successfully.
Example: POST /api/test/user returns 201 when name and email are valid.
The server could not understand the request — often invalid JSON or missing required fields.
Example: POST /api/test/user without an email returns 400.
Authentication failed or was missing.
Example: GET /api/test/auth without Bearer demo-token returns 401.
You are authenticated but not allowed to access this resource.
Example: GET /api/messages with a non-admin token returns 403.
The URL or resource does not exist.
Example: GET /api/blog/nonexistent-slug/content returns 404.
Something went wrong on the server. Retry later or check server logs if you own the API.
Example: Rare on demo endpoints; more common when upstream services fail.
Every route handler under /api/ on this site. Sandbox and safe-to-try endpoints are documented below with Postman walkthroughs; protected routes are listed for context only.
| Method | Path | Scope | Writes data |
|---|---|---|---|
| GET | /api/test/hello | Sandbox | No |
| POST | /api/test/user | Sandbox | No |
| PUT | /api/test/user | Sandbox | No |
| DELETE | /api/test/user | Sandbox | No |
| GET | /api/test/auth | Sandbox | No |
| OPTIONS | /api/test/* | Sandbox | No |
| GET | /api/chat | Health check | No |
| GET | /api/blog/{slug}/content | Public read | No |
| POST | /api/messages | Contact form | Yes |
| GET | /api/messages | Admin only | No |
| POST | /api/chat | AI streaming | No |
| POST | /api/chat/send | Authenticated chat | Yes |
| GET | /api/chat/status | Chat utility | No |
| POST | /api/drop | File upload | Yes |
| POST | /api/upload | Dashboard upload | Yes |
| POST | /api/blog/generate | Admin AI | Yes |
These endpoints are safe for learning. They return sample data only and never modify production systems.
The simplest possible API call. Use this to confirm Postman is working before trying POST or authentication.
URL
https://elangodev.com/api/test/hellocurl
curl -X GET "https://elangodev.com/api/test/hello"
Success — HTTP 200
{
"success": true,
"message": "Hello from API"
}Common mistakes
Sends a JSON body with name and email. Returns 201 Created on success or 400 when validation fails.
URL
https://elangodev.com/api/test/userHeaders
Content-Type: application/json
Request Body
{
"name": "John",
"email": "john@example.com"
}curl
curl -X POST "https://elangodev.com/api/test/user" \
-H "Content-Type: application/json" \
-d '{"name":"John","email":"john@example.com"}'Success — HTTP 201
{
"success": true,
"message": "User created",
"data": {
"name": "John",
"email": "john@example.com"
}
}Failure — HTTP 400
{
"success": false,
"message": "Email is required"
}Common mistakes
Practice updating a resource. Same JSON shape as POST; optional id field is echoed back in the response.
URL
https://elangodev.com/api/test/userHeaders
Content-Type: application/json
Request Body
{
"id": "demo-user-1",
"name": "Jane",
"email": "jane@example.com"
}curl
curl -X PUT "https://elangodev.com/api/test/user" \
-H "Content-Type: application/json" \
-d '{"id":"demo-user-1","name":"Jane","email":"jane@example.com"}'Success — HTTP 200
{
"success": true,
"message": "User updated",
"data": {
"id": "demo-user-1",
"name": "Jane",
"email": "jane@example.com"
}
}Failure — HTTP 400
{
"success": false,
"message": "Name is required"
}Common mistakes
Practice DELETE with a query parameter. No request body is needed.
URL
https://elangodev.com/api/test/user?id=demo-user-1Query Params
curl
curl -X DELETE "https://elangodev.com/api/test/user?id=demo-user-1"
Success — HTTP 200
{
"success": true,
"message": "User deleted",
"data": {
"id": "demo-user-1"
}
}Failure — HTTP 400
{
"success": false,
"message": "Query parameter 'id' is required"
}Common mistakes
Protected endpoints require an Authorization header. This demo accepts only the public sample token demo-token.
URL
https://elangodev.com/api/test/authHeaders
Authorization: Bearer demo-token
curl
curl -X GET "https://elangodev.com/api/test/auth" \ -H "Authorization: Bearer demo-token"
Success — HTTP 200
{
"success": true,
"message": "Authenticated"
}Failure — HTTP 401
{
"success": false,
"message": "Invalid token"
}Common mistakes
These are real endpoints with read-only or clearly scoped behavior. Admin, upload, and AI chat routes are intentionally excluded from this guide.
A read-only production health endpoint. Useful for checking that the API server is reachable. Does not invoke AI or consume quota.
URL
https://elangodev.com/api/chatcurl
curl -X GET "https://elangodev.com/api/chat"
Success — HTTP 200
{
"status": "AI Route is UP"
}Common mistakes
Fetches a published blog post as JSON when Accept: application/json is set. Replace {slug} with a real post slug from /blog.
URL
https://elangodev.com/api/blog/your-article-slug/contentHeaders
Accept: application/json
curl
curl -X GET "https://elangodev.com/api/blog/your-article-slug/content" \ -H "Accept: application/json"
Success — HTTP 200
{
"title": "Example Article Title",
"slug": "example-slug",
"excerpt": "Short summary of the article.",
"content": "Plain-text article body.",
"html": "<p>Rendered HTML article body.</p>",
"tags": [
"nextjs",
"api"
],
"published_at": "2026-01-15T00:00:00.000Z",
"url": "https://elangodev.com/blog/example-slug"
}Failure — HTTP 404
{
"message": "Article not found"
}Common mistakes
Public contact form API. Saves a real message to the database — use clearly fake test data only. Do not abuse this endpoint.
URL
https://elangodev.com/api/messagesHeaders
Content-Type: application/json
Request Body
{
"fullname": "Test User",
"email": "test@example.com",
"message": "This is a practice message from the API testing guide."
}curl
curl -X POST "https://elangodev.com/api/messages" \
-H "Content-Type: application/json" \
-d '{"fullname":"Test User","email":"test@example.com","message":"This is a practice message from the API testing guide."}'Success — HTTP 201
{
"success": true,
"message": "Message sent successfully"
}Failure — HTTP 400
{
"success": false,
"error": "Email, fullname, and message are required"
}Common mistakes
Copy any command into your terminal. These match the Postman examples above and work on macOS, Linux, and Windows with curl installed.
curl -X GET "https://elangodev.com/api/test/hello"
curl -X POST "https://elangodev.com/api/test/user" \
-H "Content-Type: application/json" \
-d '{"name":"John","email":"john@example.com"}'curl -X PUT "https://elangodev.com/api/test/user" \
-H "Content-Type: application/json" \
-d '{"id":"demo-user-1","name":"Jane","email":"jane@example.com"}'curl -X DELETE "https://elangodev.com/api/test/user?id=demo-user-1"
curl -X GET "https://elangodev.com/api/test/auth" \ -H "Authorization: Bearer demo-token"
curl -X GET "https://elangodev.com/api/chat"
curl -X GET "https://elangodev.com/api/blog/your-article-slug/content" \ -H "Accept: application/json"
curl -X POST "https://elangodev.com/api/messages" \
-H "Content-Type: application/json" \
-d '{"fullname":"Test User","email":"test@example.com","message":"This is a practice message from the API testing guide."}'These routes exist on the site but are omitted from hands-on exercises because they require authentication, stream binary data, or write to production systems.
/api/chat (POST), /api/chat/send, /api/chat/edit, /api/chat/deleteThese routes power the live AI assistant and authenticated chat. They require session tokens, may stream responses, and write to production databases.
/api/drop, /api/upload, /api/moments/uploadFile upload routes issue S3 presigned URLs and accept binary payloads. They are not suitable for beginner Postman exercises without real credentials.
/api/blog/generate, /api/blog/suggestAdmin-only AI content tools that call Gemini and modify blog data. Protected by authentication and API quotas.
GET /api/messagesReturns all contact messages and requires a valid admin Bearer token from Supabase auth. Documented here for awareness only — do not attempt without authorization.
Deeper explanations live in the Engineering Handbook and technical blog.
UI-focused QA — test cases, smoke checks, browser DevTools, and practice scenarios on this site's public pages. Pairs with API testing when forms fail.
Read moreBrowsers block cross-origin fetch() calls unless the server sends Access-Control-Allow-Origin. Postman ignores CORS — if Postman works but your browser does not, CORS is the likely cause.
Read moreBearer tokens prove identity in the Authorization header. Demo endpoints use demo-token; production admin routes expect a real Supabase session JWT.
Read moreMost examples here are REST JSON. The homepage AI assistant uses POST /api/chat with Server-Sent Events streaming — a different protocol pattern.
Read moreIf you send JSON without Content-Type: application/json, some servers cannot parse the body. In Postman, pick raw → JSON and Postman usually sets the header for you.
Authorization headers for JWT-style tokens must use the format Bearer <token>, not just the token string. A common mistake is pasting demo-token without the Bearer prefix.
Trailing commas, single quotes, or unquoted keys break JSON. Use a JSON formatter if you are unsure — invalid JSON often produces a 400 Bad Request.
Sending GET to an endpoint that expects POST will fail or return unexpected results. Always match the method documented for each endpoint.
A response body with success: false may still come with HTTP 400 or 401. Read both the status code and the JSON message field to understand what happened.
Quick answers for beginners getting started with Postman and REST APIs.
Explore the Engineering Handbook for deeper technical concepts, or read blog articles about building production APIs with Next.js.