
Postmate Client
Postmate Client — the privacy-first API client for VS Code
I built a free Postman alternative for VS Code — 2,000 installs, 100% local, no login
If you're looking for a Postman alternative that doesn't push your data to the cloud, I built one.
Postmate Client is a free, privacy-first API testing tool that lives inside VS Code. No account. No cloud sync. No telemetry. Your API collections, tokens, and environment variables stay 100% local on your machine.
Why developers are switching from Postman:
Postman's free tier keeps shrinking
Cloud sync means your API secrets live on their servers
Paying for features that used to be free
What Postmate Client gives you for free:
REST, GraphQL, and WebSocket API testing
Pre/post request scripts (
pmscripting library)Data-driven testing with CSV data tables
Response diffing across environments (staging vs prod)
CLI (
pmc) for CI/CD pipeline integrationPostman collection import (v2.0 and v2.1)
Git-compatible local file storage
It's the local-first Postman alternative built specifically for developers who live in VS Code and don't want another SaaS subscription eating into their workflow.
Just crossed 2,000 installs as a solo dev with no marketing budget.
If you're tired of Postman, Thunder Client paywalls, or any API client that requires a login — give it a try.
🔗 postmateclient.com
🔗 VS Code Marketplace: search Postmate Client
About
I got tired of Postman pushing everything to the cloud. My API tokens and collections shouldn't live on someone else's servers. I wanted a privacy-first, 100% local API client inside VS Code — no login, no telemetry.

4 Comments
A lot of dev tools only feel worse once you realize your API data is tied to an account you didn’t really need in the first place.
One thing that stands out is how quickly local-first tools become a default once people stop trusting cloud sync for sensitive configs.
What’s been the biggest reason users stick with it — privacy concerns or just staying inside VS Code without context switching?
One thing I'd be careful with:
The interesting question may not be why developers are leaving Postman.
It may be what they're actually choosing Postmate for instead.
Those sound similar, but they can lead to very different conclusions about positioning, expansion, and which signals deserve confidence.
I wouldn't make that call casually from install growth alone.
That's a fair distinction, and honestly a useful one to sit with.
From what I can tell — looking at install patterns, the GitHub issues that come in, and how people describe their use case — the pull isn't always "I left Postman." Sometimes it's "I never wanted to leave VS Code in the first place."
That's a subtly different signal. It's not migration from a tool, it's resistance to context-switching at all. Postmate fits because it's already where they work, not because it's a better version of something else.
You're right that install growth alone doesn't tell you which of those is happening — or what it means for where to take the product next. It's something I'm actively trying to understand better rather than assume.
Possibly.
The reason I stopped short earlier is that I don't think the interesting part is whether users are avoiding Postman or avoiding context switching.
I think there's a more important decision sitting underneath that interpretation.
That's one of those things that can quietly shape positioning, roadmap decisions, and which signals end up looking like validation.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.