That’s classic, I earlier used to just go with headers for auth. But the “Bearer“ vs “bearer“ was the turning point for me. I spent quite nice time on debugging this. Then switched to in-built Auth section.
1 Like
MCP App + ESP32 + Coffee = Chaos 
Last week I attended a Postman meetup in London about MCP Apps and agentic development. Naturally, I thought: Right. I shall build an MCP App to control my Saeco Vienna via an ESP32. Looks good to me.
I followed the MCP Apps docs and built a small UI in Postman. The ESP32 runs a tiny HTTP server on my local network — expose endpoint, send command, brew coffee.
Being the early optimiser I am, I edited /etc/hosts:
127.0.0.1 mycoffee.machine
Instead of localhost:80. Fancy, right? (Little did I know that was the start of the chaos.)
What went wrong
Standard solo-dev behaviour. Business as usual. Flash ESP. Plug in. Alt+Tab. Test. Tweak UI. Repeat.
Then suddenly:
Could not send request.
Couldn’t resolve host.
How you realised the mistake
After adding logs, LEDs, and a mild existential crisis…
While furiously Alt+Tabbing, I had accidentally opened the Postman web app and switched to the Cloud Agent instead of the Desktop Agent.
Cloud Agent cannot resolve /etc/hosts or access local network devices. Of course it couldn’t reach mycoffee.machine.
What you changed afterwards
Switched back to the Desktop Agent.
Click. Select. Bob is your uncle.
Everything brewed perfectly again.
Lesson: before debugging firmware… check your Agent.
Inclusive, use the “Debug with AI” feature — it literally explains the host resolution issue.
2 Likes
Great practical takeaway too checking the Agent before debugging firmware is such a good lesson. Maybe just one short line explaining why the Cloud Agent can’t resolve local hosts would make it even clearer for newcomers.
Mistake: The “Local Value” Ghost in the New UI
What I was trying to achieve: I was setting up a shared Environment for our team’s new Payment API. I added the api_key to the environment variables so my teammates could start testing immediately without needing to hunt for credentials.
What went wrong: On my machine, every request was a smooth 200 OK. But the second my lead tried to run the collection, she got 401 Unauthorized. I kept insisting the key was there in the “Value” column. We wasted 30 minutes debugging headers before I realized that in the new Postman UI, the “Value” column defaults to local-only unless you manually share it.
How I realised the mistake: I screenshared with her and saw her api_key was empty. I hadn’t clicked the cloud icon next to my value. In the new update, if that cloud icon isn’t toggled (meaning it’s not a “Shared Value”), your teammates see absolutely nothing, even though it looks perfectly fine on your screen!
What I changed afterwards: I now make it a habit to click the three dots (…) and enable the “Shared Value” column explicitly. It gives me back that “Initial vs. Current” visibility so I can clearly see what is staying on my machine and what is actually going to the cloud for the team.
That silent failure with “NAN” in your billing monitor is a classic nightmare! I actually ran into something similar recently because of the UI updates.
It turns out that for Monitors to ‘see’ variables, they must be in the Shared Value column (which you might have to manually enable now via the three-dot menu in the variables table). If the value is only in the local column and the Cloud Icon isn’t toggled, the Postman Cloud agent essentially sees a blank space.
It’s a huge ‘gotcha’—it looks perfect on our local Runner, but the Monitor is flying blind! Great job catching that before the DJ API bill climbed any higher.
I liked how you pointed out that the issue wasn’t with the test itself but with Postman running the last saved version. The moment you noticed your fix missing in a new tab clearly showed how easy it is to forget common day to day things. Your takeaway of pressing Ctrl+S before running is a simple but really useful habit, and autosaves option as danny mentioned is great.
1 Like
Mistake: It Works Manually But Fails in Runner
What I was trying to achieve: I was load-testing a paginated API using Collection Runner to fetch multiple pages automatically.
What went wrong: Page 1 worked. Every next request returned the same data, even though I was updating the page parameter in my test script. I assumed the API pagination was broken.
How I realised the mistake: After checking the Postman Console, I saw the request URL never changed. I had updated the variable in the Tests tab, but Runner prepares the next request before Tests execute so it kept sending the old value.
Snippet :
let nextPage = pm.response.json().page + 1;
pm.environment.set(“page”, nextPage);
What I changed afterwards: Moved the logic to a Pre-request Script so the variable updates before the request is built.
Lesson: In Postman and Life, timing matters Tests validate the past, Pre-request Scripts control the future.
3 Likes
Mistake: The Test That “Should” Have Changed the Next Request
What I was trying to achieve
I was using the Collection Runner to validate a simple flow: login, then call a series of authenticated endpoints in sequence.
What went wrong
Runner kept sending the second request with the old token. I’d written a test that parsed the new token from the login response and stored it in an environment variable. The next request still used the previous value, causing 401s.
How I realised the mistake
I opened the Postman Console and noticed that the URL for the second request was built before my test ever ran. The Runner prepares the next request before executing the Tests of the current one, so my variable update arrived too late.
What I changed afterwards
I moved the token parsing into a Pre-request Script so the variable is updated before the request is built:
// Pre-request Script of "Get Profile"
const token = pm.environment.get("token");
pm.request.headers.add({
key: "Authorization",
value: `Bearer ${token}`
});
Now the sequence works reliably in Runner, CI, and Newman.
Lesson:
In Postman and in life, timing matters: Tests validate the past; Pre-request Scripts control the future.
yes! this local vs shared value thing is so confusing in the new ui I had the same issue where it worked for me but not my teammate. The cloud icon is easy to miss. Thanks for the screenshot, that’s helpful.
Nice one — the part about Runner preparing the next request before Tests execute is a really good catch. Easy to assume pagination is wrong when it’s actually just script timing. Moving it to Pre-request Script makes total sense 
. Another thing that helped me was logging the variable in the Pre-request Script with console.log(pm.environment.get("page")) just to confirm the value before each run.
1 Like
Global scope being resolved first is so easy to overlook, especially in CI runs. Good reminder to always verify the resolved URL before assuming the environment is the problem.
I was testing a protected API using a Bearer token stored in an environment variable. My goal was to automate login → save token → reuse it in all requests.
What went wrong: Requests randomly started failing with 401 Unauthorized, even though login was successful.
How I realized: Postman Console showed the token was undefined in some requests. I had saved the token as a local variable instead of an environment variable.
What I changed: Stored token correctly and added a safety test.
Snippet
let data = pm.response.json();
pm.environment.set("auth_token", data.token);
pm.test("Token exists", function () {
pm.expect(pm.environment.get("auth_token")).to.not.be.undefined;
});
Thanks, Joyston! Var scope hell unites us 
Your hidden newline story is my new nightmare fuel.
Wow, thanks Danny! Coming from you means a lot. Docs addition would save everyone agree on Runner/Monitor diffs!
Why: Monitors run in cloud → need synced ‘Shared Value’ (not local). Logs were the giveaway!"
The challenge is now closed.
Thank you to everyone who submitted and responded to others. 
We’re now reviewing the entries and will announce the winner tomorrow 
This has been the behaviour in Postman, while using variables, and been part of the docs for many years. 
1 Like
Challenge winner
Congrats to @shankarbisht1224 for sharing a very common mistake around saving requests and what you can do in your own set up to mitigate against this in the future.
Winning entry → 💥 $100 Community Challenge – Postman Mistakes That Taught Me Something | 24 Hours Only - #3 by shankarbisht1224
New challenge drops next week.
4 Likes