I spent a lot of time reading through multiple Reddit (primarily) and X discussions about the recent Postman changes, and it was fascinating to see what developers are struggling with and what they really care about in an API tool.
These are my key take aways:
<ol>
<li>Git-native is non-negotiable</li>
</ol>
-Developers want API collections and tests living alongside their code.
-Anything cloud-only or proprietary immediately adds friction and slows teams down.
<ol>
<li>Local-first builds trust</li>
</ol>
-Much of the discussion wasn’t about features at all. It was about control, ownership, and avoiding vendor lock-in.
-When requests, environments, or secrets live on someone else’s servers, trust disappears.
<ol>
<li>Reliable imports reduce switching costs</li>
</ol>
-OpenAPI, HAR, and collection parsing are critical.
-If a tool can’t reliably import existing work, migrating away from an old tool becomes painful.
Postman still dominates mindshare here, largely due to import reliability.
<ol>
<li>Speed matters more than feature lists</li>
</ol>
-Developers value tools that are fast, lightweight, and focused.
-Most don’t want bloated “enterprise dashboards” just to send requests.
<ol>
<li>Secrets handling is underrated but crucial</li>
</ol>
Devs want:
-Automatic reading from existing environment variables
-No duplicate configuration
-Smooth integration with secret managers
-Git-friendly workflows
One comment summed it up perfectly:
“Figure out a way for it to grab secrets via loaded environment variables and you’ve got yourself something very special.”
<ol>
<li>Automation is powerful but selective</li>
</ol>
-Visual flows, request chaining, and reusable sequences excite some teams — especially for end-to-end API testing.
-Others just need something that works reliably with minimal setup.
The bigger takeaway?
Many see this as a “feature war,” but really, it’s a trust war.
Its possible that the winning tools are no the ones with the flashiest tabs or AI integrations etc. but the ones who simply respect developer workflows.
This discussion resonated deeply, because when we decided to open source Voiden, this is exactly what we had in mind:
Not just another API client, but a tool that aligns with how developers think and work.
This is the repo to have a look: <a href="https://github.com/VoidenHQ/voiden" target="_blank" rel="noopener nofollow">https://github.com/VoidenHQ/voiden</a>
Have you been following the discussions? Is there anything else you noted/noticed?

Nikolas Dimitroulakis

Analysis of developer feedback on recent Postman changes reveals six key priorities: git-native workflows where API collections live alongside code, local-first architecture to avoid vendor lock-in, reliable import capabilities for OpenAPI and HAR formats, speed over feature bloat, seamless secrets handling through environment variables, and selective automation for testing. The core insight is that developers prioritize trust and workflow alignment over flashy features, favoring tools that respect existing development practices rather than forcing cloud-only or proprietary solutions.

Reading Between the Lines: Postman Changes and What Devs Value