Lesson 1 of 85 min read
Install Postman and send your first request
Postman lets you call any API without writing code. In five minutes you will send a real request and read the answer.
Key takeaways
- 1Download the free Postman app (or use the web version) and create a workspace for your practice.
- 2Click New > HTTP, choose GET, paste a URL and press Send.
- 3Read the response: status code, time, size, and the JSON body in Pretty view.
Try it now
GET https://softwaretestpilot.com/api/public/demoshop/products Expected: - Status: 200 OK - Body: a JSON array of products, each with id, name and price - Time: usually well under one second
Go deeper
Expert notes beyond the basics
- 01
Read the whole response, not just the body
The Headers tab shows Content-Type, caching and rate-limit headers. The time and size help you spot slow or oversized responses early.
- 02
Use the Console
View > Show Postman Console shows the exact request sent, including headers and resolved variables. It is the first place to look when something doesn't work.
- 03
Response headers tell their own story
Beyond Content-Type, look at Cache-Control to see if a response can be cached, X-RateLimit headers to see how many requests you have left, and any custom headers an API adds for tracing, like X-Request-Id. Reading headers, not only the JSON body, often explains odd behaviour such as stale data or sudden 429 errors.
- 04
Postman is also a quick exploratory tool
Before writing any automated checks, use Postman to explore an unfamiliar API: try valid and invalid inputs by hand, see how error messages look, and note undocumented fields. This manual exploration, done in the first few minutes with a new API, often surfaces assumptions the documentation got wrong before you invest time scripting checks.
Common mistakes to avoid
- - Testing only in the browser address bar, which can only send GET.
- - Ignoring the status code because the body 'looks fine'.
- - Never checking response headers, missing clues about caching or rate limits.
- - Jumping straight to scripting tests without first exploring the API manually to understand its real behaviour.
Try it yourself
Send GET /products/1 and GET /products/99999 on the Demo Shop API. Write down both status codes.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
Why do testers use Postman?
Model answer
It makes exploring and testing APIs fast: you can send any request, inspect responses, save requests in collections, add automatic checks and later run the same collection in CI with Newman, all without a full coding framework.
- Q2
What does the Postman Console show?
Model answer
The raw request and response for every call, including resolved variables, headers and console.log output from scripts. It is the main debugging tool.
- Q3
What is the difference between the response time shown in Postman and real user-perceived latency?
Model answer
Postman's time measures only the network round trip for that single request, not page rendering, multiple parallel calls, or client-side processing a real app does. It is a useful early signal of backend performance but is not the same as the full user experience.
- Q4
Why might a request work in a browser but fail in Postman, or the other way round?
Model answer
Browsers automatically send cookies, default headers and follow CORS rules, while Postman sends exactly what you configure and ignores CORS by default. Differences in headers, cookies or authentication state between the two are the most common causes of this mismatch.
Knowledge check
+5 points
Where do you see whether a request succeeded?