Imagine writing a letter. You write the full address on every single letter — street, city, pin code. 200 letters. Then your friend moves. You now rewrite all 200 letters. That is what hardcoded URLs feel like in Postman.
A variable is your address book. Write the address once. Reference it everywhere. Friend moves? Update one entry. All 200 letters point to the new place.
You have 50 requests. All pointing to https://www.testerrank.com/api. Dev server goes down. Team says "use staging." You now open 50 requests and change the URL one by one. Miss one? That request hits localhost. You get a confusing "connection refused" error and waste 30 minutes debugging what turned out to be a typo.
Key Point: Variables are not a nice-to-have. They are survival gear. Any collection without variables will break the moment you switch environments, share with a teammate, or rotate a token.
Variables in Postman use double curly braces: {{variableName}}. That's the syntax. Anywhere you can type text — URL, headers, body, pre-request scripts — you can use {{variables}}.
// Hardcoded request
GET https://www.testerrank.com/api/users/42
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.hardcoded.token
// Same request with variables
GET {{baseUrl}}/users/{{userId}}
Authorization: Bearer {{authToken}}Q: Why should we use variables in Postman instead of hardcoding values?
A: Variables eliminate repetition and reduce errors. When a value like base URL or token changes, you update it in one place instead of editing every request. Variables also enable environment switching (dev/staging/prod), team collaboration (each person sets their own values), and data-driven testing (run same request with different inputs). In real projects with 100+ requests, hardcoding is simply unmanageable.
Key Point: Variables replace hardcoded values with reusable references. Update once, reflected everywhere. Syntax: {{variableName}}.