DEV Community: Shyam Narayan Yadav

How I Built an AI QA Agent for API Regression and Other Testing Tasks

Shyam Narayan Yadav — Tue, 29 Sep 2026 02:46:40 +0000

Write API test scenarios in natural language and let an AI agent run them with Postmate MCP. No scripts to maintain.

In short: to build a QA agent for API testing, you need four things: a skill file with business rules and test scenarios in plain English, a data table with test values, saved API requests, and an AI agent (like GitHub Copilot) that sends those requests through an MCP server such as Postmate's and judges the responses.

For years, API regression testing meant the same routine for me: write a request, write a script to assert on the response, repeat a few hundred times. Then, every time the API changed, spend days fixing the scripts instead of testing.

A few weeks ago at my day job, I tried something different. I built my first QA agent. It runs our entire regression suite against the application, and I did not write a single test script for it.

The biggest win wasn't speed. It was maintenance. Keeping business rules in natural language turned out to be far easier than keeping an automation codebase alive.

I can't share that code or those screenshots, so I rebuilt the whole thing from scratch on my personal laptop against a demo school management app. Everything you see in this post is from that rebuild, and you can reproduce it with free tools.

What I liked most

Before the how, here's why I'm excited about this approach. Four things stood out:

There is no test script. No pm.test, no expect, no assertion code to maintain.
The agent calls the API itself. It uses the send_request tool from Postmate's local MCP server, running inside VS Code, to send real requests and read real responses. No cloud relay, no API keys handed to a third party.
The knowledge lives in a skill file. The business rules and the test scenarios are written in plain English in one Markdown file. The agent reads it and follows it.
Test data is separate. Values live in a data table, so adding a new test case means adding a row, not touching the scenarios.

In other words: I describe what the application should do, the data table says with which values, and the agent figures out how to check it.

The architecture

The diagram at the top of this post shows the whole setup. There are only five moving parts:

Skill file: application knowledge plus test scenarios, in plain English.
Test data table: a Postmate data table (CSV) with one row per test case.
Copilot agent (VS Code): a custom agent that reads the skill and the data, decides which requests to send, and judges the responses.
Postmate MCP server: exposes tools like send_request, which runs a saved request from a Postmate collection with the environment and data values the agent passes in.
The application under test: in this demo, a school management API.

Postmate is a local-first API client for VS Code. Collections, environments, data tables and results are stored as files in your workspace, with no account and no cloud sync (how Postmate handles your data). The MCP server runs inside the editor, bound to 127.0.0.1.

Postmate never calls an AI model. Your AI agent (Copilot, in this case) calls Postmate.

The demo app

The demo is a school management system I built a couple of years ago: a .NET 8 Web API with MySQL behind it. It manages grades, fees, students, staff and payments. All of its data is dummy data, which makes it a safe place to let an agent create and delete things.

For this post I'm focusing on one complete workflow: fees. A school admin creates a fee (say, an annual lab fee for Eighth grade), the fee should show up for that grade and not for others, and deleting it should remove it everywhere.

It sounds simple, but writing this as scripted tests means chaining requests, extracting IDs and names, looping over data, checking presence and absence, and cleaning up on failure. Let's see how much of that disappears.

Step 1: A collection with no scripts

I created a Postmate collection called School API with saved requests only. No assertions anywhere.

Two small decisions made a big difference later:

Readable names. Every request follows a Verb + Noun pattern: Add Fee, Get All Fees, Get Fees By Grade, Delete Fee. Postmate's send_request tool identifies a saved request by its path, CollectionName.RequestName, so the agent calls "School API.Add Fee". The skill file refers to requests by the same names, so clear names mean fewer mistakes.

Variables instead of values. Every value that changes between test cases is a variable. The Add Fee body looks like this:

{
  "feeName": "{{feeName}}",
  "feeType": "{{feeType}}",
  "amount": "{{amount}}",
  "grade": ["{{grade}}"]
}

What about authentication?

The API needs a Bearer token. Postmate's request chaining handles it, and there are two ways to set it up.

Option 1: No code, from the UI. Open the request's Pre-request → Pre Request tab, click Add Request, and pick the collection and the request to run first: School API → Login. Postmate runs Login before every request that needs it, and the token lands in the environment.

Option 2: A one-line pre-request script. If you prefer code, or need more control, the same thing takes one line in Pre-request → Scripting, using pm.getRequest().send():

const login = await pm.getRequest("School API.Login").send();
pm.environment.set("token", login.body.token);

Either way, this is setup, not a test. There are zero assertions and zero test scripts, and the agent never has to think about auth.

Step 2: Environment

I kept the base URL and login credentials in a Postmate environment:

Variable	Purpose
`schoolBaseUrl`	The API's base URL
`email`	Login email
`password`	Login password
`token`	Filled automatically by request chaining

This keeps credentials out of the skill file, the data table, and the agent's instructions, so none of them ever end up in a prompt I write or a file I share.

Step 3: The test data table

Test values go in a Postmate data table called School-fee:

_dtag,feeName,feeType,amount,grade,otherGrade
fee-annual,QA Lab Fee,Annually,750,Eighth,Fifth
fee-monthly,QA Transport Fee,Monthly,300,Ninth,Sixth
fee-onetime,QA Admission Fee,One Time,1500,Seventh,Fourth

Each row is a complete test case. otherGrade is a grade the fee was not created for, used for a negative check. The _dtag column lets the agent pick rows: the skill says "run the scenario for every row tagged fee-*".

Want to test a new fee type? Add a row. The scenario doesn't change.

Step 4: The skill file

This is the heart of the whole setup. It lives at .github/skills/school-api/SKILL.md and has three parts: application knowledge, scenarios, and test data rules.

Application knowledge is what a new QA engineer would need to know on day one:

### Fees
- A fee has a name, a type, an amount, and one or more grades it applies to.
- Valid fee types: "Annually", "Monthly", "One Time" (with a space).
- Grades are named in words (e.g. "Eighth", "Tenth"), not numbers.
- Fee names are unique within a school.
- On save, the API appends the amount to the fee name, by design.
  Example: "QA Lab Fee" with amount 750 is stored as "QA Lab Fee 750".
- Compare grades as a set: order does not matter.
- A fee applies only to the grades it was created for. It must NOT appear
  when fetching fees for any other grade.
- Deleting a fee removes it everywhere.

The scenario reads like a manual test case:

## Scenario 1: Fee lifecycle
1. Create the fee with "Add Fee" using the row's values.
   Expected: 200.
2. Fetch all fees with "Get All Fees".
   Expected: the new fee is present with name "{submitted name} {amount}",
   and the same type, amount and grades.
3. Fetch fees for the row's `grade` with "Get Fees By Grade".
   Expected: the new fee is present.
4. Fetch fees for the row's `otherGrade` with "Get Fees By Grade".
   Expected: the new fee is absent.
5. Delete the fee with "Delete Fee".
   Expected: 200.
6. Fetch all fees again.
   Expected: the fee is no longer present.
7. Fetch fees for the row's `grade` again.
   Expected: the fee is no longer present.

Cleanup: if any step fails after step 1, still run step 5.

Look at step 4. "The fee must not appear for another grade" is one line of English. As a scripted test, it's an extra request, a loop over the response, and a negative assertion.

The skill also tells the agent to add a unique suffix to each fee name on every run, so repeated runs never collide, and defines a strict report format.

Step 5: The agent

The custom agent lives at .github/agents/school-qa-agent.agent.md. It's short, because the skill does the heavy lifting. The agent file defines the role, the tools, and the guardrails:

---
description: QA agent that runs regression tests on the School API using
  Postmate saved requests. No test scripts.
tools: ['postmate/*', 'read', 'search']
---

# School QA Agent

You are a QA engineer testing the School API. You test by sending real API
requests through the Postmate MCP `send_request` tool and judging the
responses against the scenarios in the school-api skill.

## Rules
- Only use saved requests from the "School API" collection. Never create,
  edit or delete saved requests.
- `send_request` addresses a saved request as "<Collection>.<Request>".
- Pass test values as data overrides. Never hard-code values that exist
  in the data table.
- Only delete records created during this run. Never modify or delete
  records that existed before the run.
- Every run must clean up after itself, even when a step fails.
- Do not guess. If a response is unclear, say so instead of marking PASS.
- Never print passwords or tokens.

Two things worth noting. First, the tools list is deliberately small. The agent can read files and use Postmate, nothing else, so it stays focused on testing. Second, the guardrails matter more than they look. You'll see why in a moment.

Finally, turn on the Postmate MCP server in VS Code settings (postmate.mcp.enabled, plus postmate.mcp.allowSend so the agent can send requests). The MCP Server Reference lists every tool and setting.

The final project structure:

school-api/
├── .github/
│   ├── agents/
│   │   └── school-qa-agent.agent.md
│   └── skills/
│       └── school-api/
│           └── SKILL.md
└── .postmate/
    ├── collections/
    ├── data/
    ├── reports/
    └── postmate-envs.json

Running it: three runs, three lessons

I selected the agent in Copilot Chat and typed one line:

Run fee regression.

Run 1: The agent reviewed my test setup

The first run sent zero requests, and it was still one of the most impressive things I've seen an agent do.

Before sending anything, the agent read the saved requests and noticed that Add Fee and Delete Fee were still pointing at localhost from my local testing, not the environment's base URL. It also noticed that Get Fees By Grade had the grade header hard-coded to Eighth, which would make the negative check meaningless.

It refused to run, marked the steps as blocked, and told me the exact file and line numbers to fix.

No scripted test suite would have done that. A script would have happily sent requests to the wrong place and reported whatever came back.

Run 2: It learned something about the app, and refused to take a risk

After fixing the URLs, the second run got further. The agent created a fee and found it in the list, but noticed that the stored name had the amount appended: QA Lab Fee 20260926-0510-01 750.

Then it hit a problem: my Delete Fee request still had a hard-coded fee name in its body, so it couldn't target the fee it had just created. Instead of guessing, it stopped, left the data alone, and explained why:

I stopped rather than risk deleting a pre-existing record.

That's the guardrail doing its job. It also showed me something I'd forgotten about my own app: appending the amount to the name is by design. That became one line in the skill's application knowledge.

Notice also how the agent generated the unique suffix. The skill only said "append a unique suffix, e.g. the current time". The agent chose 20260926-0510-01: date, time and row number. I described the intent; it chose a sensible implementation.

Run 3: 21 out of 21

With the delete request fixed and the naming rule in the skill, the third run went through cleanly:

3 data rows
21 requests sent
21 steps passed, 0 failed
Every fee created during the run deleted and verified absent
About 1 minute 17 seconds

And then the part I didn't ask for. Under "Observations", the agent pointed out that for the monthly fee, Get All Fees reported an amount of 300 while Get Fees By Grade reported 50. My scenario only checked whether the fee was present, so it passed, but the agent flagged the inconsistency as something a developer might want to look at, without marking it as a failure.

It also noticed two older test fees left over from earlier runs and left them alone, because they existed before this run started. The guardrail, again.

That's the difference between running a checklist and actually paying attention.

Beyond regression: just ask

The same agent is useful between regression runs too. When something looked off, I didn't open a dashboard or write a quick script. I asked:

Is Add Fee working? or env is down?

Add Fee is a POST, so the only honest way to check it was to create something. The agent created a probe fee, confirmed the API returned 200, verified that authentication and request chaining worked, deleted the probe fee, and told me the earlier failures came from saved-request configuration and stale authentication, not an outage.

Smoke checks, triage, "is it me or the server?" questions: that's the "other testing tasks" in the title. The skill file already gives the agent enough context to answer them.

What I learned

The skill file is the test suite. When the app behaviour changed my understanding (the amount in the name), I didn't rewrite assertions. I added one sentence of application knowledge.

The agent tests your test setup too. Hard-coded URLs, stale headers and fixed values in request bodies are exactly the kind of bugs that silently rot scripted suites. The agent caught all of them, most before sending a single request.

Guardrails aren't optional. An agent that can call Delete needs clear rules about what it may delete. "Only delete records created during this run" prevented real damage.

Naming is part of the interface. Clear request names, variables everywhere, and one data table made the agent's job, and my debugging, much easier.

Limitations (the honest part)

This approach isn't magic, and I don't want to pretend it is.

It's not fully deterministic. On one later run where everything passed, the agent returned a summary instead of the report table I'd asked for. The fix was to make the report format stricter ("always produce this table, even when everything passes"). But it's a reminder that instructions need to be explicit, because an LLM will fill gaps with its own judgement.

It's slower than a script. A minute for 21 requests is fine for regression, but a scripted runner will always be faster. This is not a replacement for load or performance tests.

LLM judgement isn't a contract. For things that must never change, like status codes, required fields and response schemas, deterministic assertions still have their place, and Postmate can generate those test scripts with AI too. I see the agent as the layer on top: business rules, workflows and cross-endpoint behaviour that are painful to script.

The model sees the responses. Whatever send_request returns is read by your agent's LLM. For internal or regulated APIs, use test data and choose your agent and model accordingly.

It mutates real data. Mine is a demo app with dummy data. On a real system, run it against a test environment, use a clear naming prefix for test data, and keep the cleanup and deletion guardrails.

From TDD to SDD

A few days ago I joked in a LinkedIn thread that the "new boy" after TDD is SDD: spec-driven development. Building this agent made me take that more seriously.

Waterfall taught us to plan. TDD taught us to test first. BDD taught us to describe behaviour in plain language. This setup takes the next step: the plain-language spec isn't documentation that drifts out of date. It's the thing that actually runs.

The acronym changes. The good ideas survive.

Try it yourself

Everything in this post uses:

VS Code with GitHub Copilot (agent mode and custom agents)
Postmate Client, a free, local-first API client for VS Code, with its built-in MCP server

Install Postmate from the VS Code Marketplace (PostMate-lab.postmate), from Open VSX if you use Cursor, Windsurf or VSCodium, or visit postmateclient.com. The getting started guide takes a few minutes. Then point it at an API you own, write three scenarios in plain English, and see what your agent finds.

I'd love to hear what it catches for you.

Originally published on the Postmate blog.

HTTP QUERY Method (RFC 10008) Explained: GET's Safety, POST's Body

Shyam Narayan Yadav — Mon, 20 Jul 2026 00:38:46 +0000

In June 2026 the IETF published RFC 10008, and HTTP got its first new method in 16 years: QUERY. The last time this happened was PATCH, back in 2010.

QUERY exists to kill one of the oldest workarounds in API design: POST /search. If you've ever POSTed a request that didn't actually change anything — just because your filter wouldn't fit in a URL — this method is for you.

What is the HTTP QUERY method?

QUERY is a safe, idempotent HTTP method that carries a request body. Think of it as GET's guarantees with POST's payload:

QUERY /users HTTP/1.1
Content-Type: application/json

{ "filter": "age > 21", "fields": ["name", "email"], "limit": 10 }

The semantics in one line each:

Safe — the client is asking for data, not requesting a state change. Tooling, proxies, and crawler-like clients can treat it as read-only.
Idempotent — sending the same QUERY twice produces the same result, so clients and intermediaries may retry a failed request automatically. Nobody gets double-charged.
Cacheable — responses can be cached like GET responses, with one twist we'll get to: the request body is part of the cache key.
Body-first — the query itself lives in the body, described by Content-Type. RFC 10008 requires servers to reject requests whose Content-Type is missing or doesn't match the body.

There's also a new response header, Accept-Query, that lets a resource advertise which query formats it understands (JSON, JSONPath, whatever — expressed in HTTP Structured Fields syntax).

Why not just use GET?

GET is the right semantics — but the query has to live in the URL, and URLs are a terrible place for a complex query:

Length limits. Servers, proxies, CDNs, and browsers all cap URL length at different, undocumented points. A long ID list or nested filter will eventually hit one of them, and it'll fail only in production, only sometimes.
Encoding pain. Nested conditions, arrays, and operators like > all have to be percent-encoded into query-string soup. Every API invents its own convention (filter[age][gt]=21, anyone?).
URLs leak. Full URLs end up in server access logs, proxy logs, browser history, and Referer headers. Put a search term or an ID list in a URL and it's now in a dozen log files you don't control.

A GET with a body isn't the answer either — the spec allows a body on GET but explicitly gives it no meaning, and real-world intermediaries drop or reject it. (Elasticsearch users have been living in this gray zone for a decade.)

Why not just use POST?

Because POST is a semantic lie for reads — and the lie has a cost. The moment you use POST, everything in the HTTP ecosystem assumes you're changing something:

No caching. Intermediaries won't cache POST responses. Your identical search request hits the origin every single time.
No safe retries. A client that times out on a POST can't safely resend it — it might create a duplicate order. So SDKs, proxies, and service meshes all refuse to auto-retry, even when your POST was secretly a read.
Tooling treats it as a write. Monitoring, API gateways, security scanners, idempotency middleware — all of them classify your search as a mutation.

POST /search became the industry standard anyway, because it was the only option that worked. QUERY is the honest verb that replaces it.

QUERY vs GET vs POST

	GET	POST	QUERY
Safe (read-only semantics)	✅	❌	✅
Idempotent (auto-retry OK)	✅	❌	✅
Cacheable response	✅	❌*	✅ (body in cache key)
Meaningful request body	❌	✅	✅
Query visible in URL/logs	✅ (that's the problem)	❌	❌
Works in every framework today	✅	✅	❌ (adoption is early)

* POST responses are technically cacheable in narrow cases nobody relies on.

The pros

Honest semantics, real benefits. Retryability and cacheability aren't academic — they're the difference between a search that survives a flaky network and one that errors out, and between a hot query hitting your database once or a thousand times.
Complex queries without URL hacks. JSON bodies with real structure, no percent-encoding, no invented query-string conventions, no length limits.
Queries stay out of logs. Bodies don't land in access logs, browser history, or Referer headers by default. For queries containing emails, IDs, or search terms, that's a privacy upgrade.
Self-describing APIs. Accept-Query gives clients a standard way to discover what query format an endpoint speaks — something POST /search never had.

The cons (and honest caveats)

Server support is early. This is the big one. Node.js parses QUERY natively, and OpenAPI 3.2 can document it, but framework routing (Rails, Spring, and friends) is still in progress. If your framework only routes the classic verbs, QUERY bounces with a 405.
Caching has sharp edges. The cache key must include the request body. A cache that normalizes or hashes bodies sloppily — treating {"a":1,"b":2} and {"b":2,"a":1} as identical, or worse, ignoring the body — opens the door to cache poisoning. Until CDN support matures, treat QUERY caching as opt-in, not automatic.
CORS preflight required. QUERY isn't a CORS-safelisted method, so browser JavaScript pays a preflight round-trip. Same as POST with application/json, so in practice you're not losing anything — but it's not free.
Ecosystem lag. Most HTTP clients, mock servers, and test tools predate the RFC. Even the public echo services (httpbingo.org, postman-echo.com) reject QUERY with a 405 today.

How to send a QUERY request today

You don't need to wait for your framework. Any HTTP client that allows custom methods can send QUERY right now. With curl:

curl -X QUERY https://echo.postmateclient.com/ \
  -H "content-type: application/json" \
  -d '{"filter":"age > 21","limit":10}'

That endpoint — echo.postmateclient.com — is (as far as I can tell) the only public echo server that accepts QUERY today. It reflects your method, headers, and body back as JSON, so you can verify the method survives the trip:

{
  "method": "QUERY",
  "path": "/",
  "body": "{\"filter\":\"age > 21\",\"limit\":10}",
  "json": { "filter": "age > 21", "limit": 10 }
}

In JavaScript, fetch sends it without complaint:

const res = await fetch("https://echo.postmateclient.com/", {
  method: "QUERY",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({ filter: "age > 21", limit: 10 }),
});
console.log(await res.json()); // { method: "QUERY", ... }

And GUI clients are starting to pick it up — Postmate Client (a VS Code API client) has QUERY in its method dropdown since v1.6.0. Postman doesn't list it yet, though you can type it as a custom method.

On the server side, a minimal Node.js handler needs zero special configuration — Node's HTTP parser already accepts QUERY, so req.method === "QUERY" just works.

Should you adopt QUERY now?

For internal APIs: yes, cautiously. You control both ends. If your stack passes QUERY through (test it — one curl tells you), you get honest semantics today, and safe retries from your service mesh for free.

For public APIs: offer it alongside POST /search, not instead. Your consumers' frameworks, SDKs, and corporate proxies are on their own timelines. The graceful pattern is the one HTTP always rewards: support both, advertise QUERY via Accept-Query, deprecate the workaround later.

For caching: wait. Let CDNs ship well-tested body-aware cache keys before you let intermediaries cache QUERY responses.

FAQ

Is QUERY a replacement for GET?

No. If your query fits comfortably in a URL, GET is still right — simpler, universally cached, zero preflight. QUERY replaces POST /search, not GET.

Is the QUERY method cacheable?

Yes — that's much of the point. Unlike POST, QUERY responses are explicitly cacheable, with the request body as part of the cache key.

Does my server need to support QUERY?

Yes. It's a real method on the wire — if your framework only routes classic verbs, you'll get a 405. Node.js parses it natively today; most frameworks are catching up.

Can I test QUERY without writing a server?

https://echo.postmateclient.com/ accepts QUERY (and any other method) and echoes the request back as JSON. The long-standing echo services predate the RFC and reject it.

Further reading: RFC 10008 at the IETF datatracker · RFC Editor info page

Postman vs Thunder Client vs Postmate Client: The Best API Testing Tool for VS Code in 2026

Shyam Narayan Yadav — Fri, 27 Mar 2026 05:56:50 +0000

If you're a developer or QA engineer who tests REST APIs regularly, you've almost certainly used Postman. It's the industry default. But in 2026, it's no longer the only serious option — and for developers who live inside Visual Studio Code, it may not even be the best one.

This post compares three tools head-to-head:

Postman — the veteran, now cloud-first
Thunder Client — the lightweight VS Code extension
Postmate Client — the new native VS Code client built for serious testing

Let's get into it.

Quick Comparison

Feature	Postman	Thunder Client	Postmate Client
Lives inside VS Code	❌	✅	✅
Free to use	Partial	Partial	✅ Free
Requires account/login	✅ Yes	Optional	❌ No
Offline support	Limited	✅	✅
pm scripting library	✅	❌	✅
Plain-English tabular tests	❌	❌	✅
Data Tables (CSV-driven testing)	❌ Free	❌ Free	✅
Request chaining via UI	❌	❌	✅
Pre-request chaining (no code)	❌	❌	✅
Variable autocomplete	✅	Limited	✅
Header autocomplete (custom)	❌	❌	✅
Collection Runner	💰 Paid	❌	✅
CI/CD CLI	💰 Paid	❌	✅
Import cURL / Swagger / Postman	✅	✅	✅
Schema validation	✅	❌	✅
No external runtime	❌	✅	✅

Postman: The Industry Standard That Became a Platform

Postman started as a simple Chrome extension for sending HTTP requests. Today it's a full SaaS platform — and that transformation is both its strength and its biggest problem for individual developers.

What Postman does well

Postman has the most mature feature set of any API tool. Collaborative workspaces, API design, mock servers, monitors, documentation generation — if your team needs an all-in-one API platform, Postman covers it. The pm scripting library is powerful and well-documented, and the ecosystem of public collections is genuinely useful.

Where Postman falls short in 2025

It's no longer a desktop tool — it's a cloud product. The free tier now requires a login, syncs your collections to Postman's servers by default, and limits collection runs to 25 per month. The Collection Runner, CI/CD integration (Newman), and team collaboration features are locked behind paid plans starting at $14/user/month.

For individual developers and QA engineers who just want to test APIs quickly and reliably, Postman has become bloated. You open a separate application, sign in, wait for it to sync, and switch context away from your editor every time you want to run a request.

The context-switching cost is real. Studies on developer productivity consistently show that switching between applications breaks flow state. If your code is in VS Code and your API client is a separate Electron app, you're paying that cost dozens of times a day.

Thunder Client: Lightweight but Limited

Thunder Client emerged as the obvious answer to Postman's bloat: a dead-simple REST client built directly into VS Code. For basic GET/POST requests during development, it works well.

What Thunder Client does well

Thunder Client is fast to install, immediately familiar (it looks like a simplified Postman), and stays out of your way for simple requests. The UI is clean and the learning curve is near zero.

Where Thunder Client falls short

The simplicity is also the ceiling. Thunder Client lacks:

A scripting library — there's no pm equivalent. You can't capture response values and pass them to the next request programmatically.
Data-driven testing — no CSV/data table support on the free plan.
Collection Runner — running a full suite sequentially requires a paid plan.
Meaningful test assertions — basic status checks only; no schema validation, no chained assertions.
CI/CD — no CLI for running collections in pipelines.

Thunder Client is genuinely useful for quick manual testing during development. But the moment you need repeatable, automated, data-driven API testing — the kind QA engineers need — it hits a wall fast.

Postmate Client: Native VS Code API Testing Built for QA

Postmate Client is a VS Code extension built specifically for developers and QA engineers who need serious testing capability without leaving their editor — and without paying for it.

It occupies a unique position: it has Postman-level scripting and testing power, Thunder Client-level VS Code integration, and it's completely free with no account required.

Stays inside VS Code — completely

Postmate Client lives in the VS Code Activity Bar. Open it, send a request, see the response — all without leaving your editor. There is no separate application, no Electron wrapper, no login, no cloud sync unless you want it.

Your collections are files in your project. Commit them to Git. Share them with teammates via your normal repo workflow. No third-party cloud involved.

The 3-second workflow

This is where Postmate Client is genuinely different. Once your project is set up with environments and data tables, sending a fully parameterised request to any environment with any test data takes exactly three steps:

Select environment — pick Dev, Staging, or Production from the Env dropdown
Select data — pick a row from your data table (start typing to filter)
Click Send

Every {{variable}} in the URL, headers, and body resolves automatically. No editing requests. No copy-pasting credentials. No switching to a spreadsheet to find the right test user.

Autocomplete everywhere

Postmate Client's request panel is built around the idea that you should almost never need to type something you've already defined:

Type {{ anywhere — URL, header value, body — and every variable from your environment and attached data table appears as a suggestion. Zero typos, zero "why isn't this variable resolving" debugging.
Type a header name and headers from your custom Manage Headers file appear as autocomplete suggestions, with the default value pre-filled automatically.
JSON path suggestions in the test panel come from the actual last response — pick the field you want to assert on from a real dropdown instead of typing $.data.users[0].id from memory.

Plain-English tabular tests — no scripting required

This is Postmate's most distinctive feature for QA engineers. Instead of writing JavaScript assertions, you write tests as table rows:

JSON Path	Operator	Expected Value	Description
`$.schoolInof.schoolName`	contains	ABC Learning Academy	Verify school name
`$.schoolInof.isAutoInvoice`	equal	true	Verify auto-invoice flag
`$.students.0.studentId`	=	6	Verify first student ID

Every row is one test. The JSON paths are suggested from the actual response. You don't write a single line of code. Results appear in the Results panel with pass/fail per row.

For QA engineers who work in JavaScript-light environments, or teams where non-developers need to write API assertions, this is transformative.

Request chaining without scripting

Postman's approach to request chaining is: write a post-request script that calls pm.environment.set() to store a value, then reference it in the next request. That's fine if you're comfortable with JavaScript.

Postmate offers the same capability via the Pre-request tab UI: select a collection, select a request, and Postmate runs it before the current request automatically. Set the captured value using a "Set to" row in the tabular test panel — no scripting required.

For teams that want chaining without code: this is the only free tool that provides it.

Full pm scripting library — when you need it

When you do need code, Postmate's pm library covers everything:

// Capture a token from login response
pm.setVariable('accessToken', RESPONSE.body.token);

// Assert with full Chai syntax  
pm.test('Status is 200', () => {
  pm.expect(RESPONSE.status).to.equal(200);
});

// Schema validation
pm.schemaTest('Valid user schema', userSchema, RESPONSE.body);

// Decode a JWT payload
const payload = pm.base64Decode(token.split('.')[1]);

The API is intentionally similar to Postman's pm library — teams migrating from Postman will find most scripts work with minor updates. See the migration guide for the full API mapping.

Data Tables: parameterise everything

Attach a CSV-style data table to an environment. Each row is a set of variable values. Use {{username}}, {{password}}, {{region}} in your requests — they resolve from whichever row you select.

The Collection Runner iterates through every row automatically: three test users in your data table means three full collection runs, each with different credentials, no duplication.

This is the feature that unlocks proper data-driven testing — and it's free, with no row limits.

CI/CD with the Postmate CLI

The Postmate CLI wraps the Collection Runner for headless execution:

postmate run \
  --collection ./collections/school-api.json \
  --environment ./environments/staging.json \
  --data ./data/test-users.csv \
  --reporter html \
  --output ./reports/results.html

Drop this into GitHub Actions, GitLab CI, or any pipeline. Exit code 0 = all tests passed. Exit code 1 = failures. The HTML report is uploadable as a build artifact.

Postman charges for Newman (their CLI equivalent). Postmate CLI is free.

Head-to-Head: Real-World Scenarios

Scenario 1: QA engineer testing a multi-tenant SaaS

You have 5 environments (dev, staging, prod, client-A, client-B) and 20 test users per environment. You need to run 30 API requests against every combination before each release.

Postman: Possible, but Collection Runner is paid. Managing 100 environments/variable sets is clunky. You'll write a lot of scripts.
Thunder Client: Not feasible without significant paid upgrade. No data table support.
Postmate Client: This is exactly the use case it's built for. Set up 5 environments, attach a data table with 20 rows each, run the Collection Runner — done. Free, entirely inside VS Code.

Scenario 2: Solo developer building and testing an API

You're building a REST API in VS Code. You want to quickly fire requests to check your endpoints as you code.

Postman: Works, but it's a separate app. The overhead of switching context 50 times a day adds up.
Thunder Client: Good fit. Simple, fast, right there in VS Code.
Postmate Client: Equally good fit, with more headroom as your testing needs grow. Start simple, add data tables and scripts when you need them.

Scenario 3: Team wanting to version-control API tests

You want your API tests in the same Git repo as your code, reviewed in PRs, and run in CI.

Postman: Collections can be exported, but the natural workflow pushes you toward Postman's cloud sync rather than Git.
Thunder Client: Collections are local files — this works reasonably well.
Postmate Client: Collections are local JSON files by design. Export, commit, PR, CI — exactly like source code. The CLI runs them in any pipeline.

Migration from Postman to Postmate Client

If you're already on Postman, migrating is straightforward:

Export your Postman collection as Collection v2.1 JSON
In Postmate Client, click Import → Postman Collection
Update scripts: pm.environment.set(k, v) → pm.setVariable(k, v), pm.response.json() → RESPONSE.body

Most collections migrate in under 10 minutes.

Conclusion: Which Tool Should You Use?

Use Postman if:

Your team needs collaborative workspaces, API design, and mock servers
You're already deeply invested in the Postman ecosystem
You have budget for the paid plan and need enterprise features

Use Thunder Client if:

You just need quick manual request testing during development
You want the absolute simplest possible tool
You don't need automation, scripting, or data-driven testing

Use Postmate Client if:

You live in VS Code and hate switching context
You need serious testing capability — data tables, scripting, collection runner, CI/CD
You want Postman-level power without Postman's price tag or account requirements
You're a QA engineer who wants to write tests without writing code

Postmate Client is free, installs in 30 seconds, and requires no account. If you test APIs from VS Code, there is no reason not to try it.

👉 Install Postmate Client from the VS Code Marketplace

👉 Read the full documentation

Have questions or feedback? Open an issue on GitHub or leave a comment below.

API Testing Tools and Data Privacy: Why You Should Stop Sending API Data to the Cloud

Shyam Narayan Yadav — Sun, 22 Mar 2026 19:28:59 +0000

Looking for secure API testing tools or a Postman alternative? You might be unknowingly sending sensitive API data to the cloud. In this post, we’ll explore why data privacy in API testing matters and how to choose a local API testing tool that keeps your data safe.

How Cloud-Based API Testing Tools Handle Your Data

Like most developers, I used API testing tools without thinking twice.

They were convenient:

Sync across devices
Save collections
Collaborate with teams

But then I realized something important…

👉 Many API testing tools store your data in the cloud.

That includes:

API keys
Authorization headers
Request and response payloads
Internal endpoints

Even if the platform is secure, your data is now:

Stored externally
Transmitted over the internet
Dependent on third-party infrastructure

Why Data Privacy Is Critical in API Testing

When working with APIs, you're often handling sensitive information.

Think about:

Payment APIs
User data
Internal microservices
Authentication tokens

Using cloud-based API testing tools in these scenarios can:

Increase your attack surface
Introduce compliance risks
Expose internal systems unintentionally

For companies, this isn’t just a technical issue — it’s a security and policy concern.

“It’s Just Dev Data”… or Is It?

It’s easy to assume:

“This is just development data, it doesn’t matter.”

But in reality:

Dev and staging environments often mirror production
Tokens may still be valid or reusable
Logs and history can persist in cloud systems

👉 Small exposure today can become a big problem tomorrow

🧠 What to Look for in a Secure API Testing Tool

After realizing the risks, I started looking for a better approach.

Here’s what actually matters in a secure API testing tool:

✅ Local data storage (no external servers)
✅ No mandatory login
✅ Lightweight and fast
✅ Seamless developer workflow integration

In short, I wanted an offline API testing tool that behaves like a developer tool — not a platform.

A Local API Testing Tool That Keeps Your Data Private

That’s when I switched to a local API testing tool — a VS Code extension called Postmate Client.

What stood out to me:

✔️ Runs 100% locally
✔️ No account or login required
✔️ No cloud sync — your data stays on your machine
✔️ Fast, simple, and developer-friendly

It fits naturally into my workflow and removes the concern of sending API data outside my environment.

Cloud vs Local API Testing Tools

Here’s a quick comparison to put things into perspective:

Feature	Cloud-Based API Testing Tools	Local API Testing Tools
Data Storage	External servers	Local machine
Login Requirement	Usually required	Not required
Privacy Risk	Higher	Minimal
Performance	Depends on network	Fast & local
Setup Complexity	Heavier	Lightweight

If you're exploring Postman alternatives, local-first tools are worth considering — especially when privacy matters.

A Better Approach to API Testing

As developers, we care deeply about:

Code quality
Performance
Security

But we often overlook the privacy of the tools we use.

Maybe it’s time to start asking:

“Do I really need my API data to leave my machine?”

Final Thoughts

Switching to a local API testing tool wasn’t about features — it was about control.

If you:

Work with sensitive APIs
Care about security and compliance
Prefer lightweight developer tools

👉 A privacy-first API testing approach just makes sense.

You don’t have to abandon cloud tools completely.

But being intentional about where your data lives can make a big difference.

Why Postmate Client Stands Out

While Postman and Thunder Client are popular choices for API testing, they both involve some form of cloud dependency—whether it’s mandatory login, optional sync, or storing collections remotely. For developers and teams prioritizing data privacy, this can be a dealbreaker.

This is where Postmate Client shines:

100% local operation — no cloud storage, no external servers

No login required — your API keys, tokens, and requests never leave your machine

Lightweight and fast — integrates seamlessly into VS Code, keeping your workflow smooth

Privacy-first mindset — designed for developers who want full control over their data

Ready to stop sending your API data to the cloud? Try Postmate Client and bring your API testing back under your control.

Built a lightweight Postman alternative inside VS Code 🚀 Fast, 100% local, and no context switching. Supports automation, Swagger import, reporting, and CLI. Would love your feedback!

Shyam Narayan Yadav — Fri, 20 Mar 2026 21:59:56 +0000

Shyam Narayan Yadav

Mar 19

Postman Alternative in VS Code: Postmate Client API Testing Tool

#vscode #api #webdev #restapi

3 min read

Postman Alternative in VS Code: Postmate Client API Testing Tool

Shyam Narayan Yadav — Thu, 19 Mar 2026 04:56:33 +0000

Postmate Client — a fast, powerful, and fully native VS Code extension that brings Postman-level API testing right into your editor, without the bloat, cloud dependency, or context switching.

If you're looking for a Postman alternative in VS Code, Postmate Client is a lightweight REST client for API testing, designed for speed and efficiency inside VS Code.

Growing buzz in QA and developer communities, it's quickly becoming a go-to tool for developers looking for a lightweight Postman alternative in VS Code with better performance and privacy.

Why Postmate Client Stands Out as a VS Code API Testing Tool

Postmate Client strikes an impressive balance: it's lightweight, powerful, and deeply integrated into VS Code's native experience, making it a strong Postman alternative for developers working in VS Code.

Key highlights include:

Built-in pm Library for Scripting — Just like Postman, you get a global pm object with handy methods such as:

pm.test(), 
pm.expect(), 
pm.assert()
pm.setVariable(), 
pm.getVariable()
//Advanced helpers like 
pm.schemaTest()
pm.base64Decode()

Easy Request Creation & Imports — Paste cURL commands and instantly test APIs. Import APIs from Swagger/OpenAPI specs or existing Postman collections into your VS Code API testing workflow.
Smart Testing & Automation — Write pre- and post-request scripts in JavaScript or use simple assertions. Easily test REST APIs in VS Code, chain requests, run collections, and view detailed execution results.
Data-Driven API Testing — Manage multiple datasets, parameterize requests with {{variable}}, and handle complex API testing scenarios in VS Code.
Environments & Variables — Full support for environments, dynamic variables, and persistent request history—everything you expect from a modern API testing tool.

Built-in API Test Reporting

Example of Postmate Client API test report

Postmate Client doesn’t just help you test APIs — it also provides powerful API test reporting directly inside VS Code.

After running requests or collections, you get an in-app summary report with:

Total requests and tests
Passed and failed assertions
Response status and execution time
Step-by-step validation results

In addition, Postmate Client can generate detailed, shareable HTML reports, making it easy to:

Share results with your team
Document API test runs
Track and review failures outside VS Code

This makes Postmate Client a complete API testing and reporting tool in VS Code, without needing external reporting tools or cloud services.

CLI Support for API Testing Automation

Postmate Client includes a CLI tool for running API tests from the command line, making it easy to integrate API testing into CI/CD pipelines and automation workflows.

Unlike many API tools, Postmate Client keeps everything local, fast, and integrated, giving you a smooth reporting experience right inside your editor.

Postmate Client vs Postman: Best Postman Alternative in VS Code?

If you're deciding between Postmate Client and Postman, the key difference is simplicity vs ecosystem.

Postman: feature-rich API platform with collaboration and cloud features, but can feel heavy for simple API testing.
Postmate Client: a lightweight API testing tool in VS Code that is fast, 100% local, free, and fully integrated into your development workflow.

For developers looking for a Postman alternative in VS Code, Postmate Client is ideal for fast, focused REST API testing without leaving the editor.

Get Started

📘 Documentation – Setup, guides, and API testing examples: https://www.postmateclient.com/
🎥 Video Tutorial – Learn API testing in VS Code step by step: https://www.youtube.com/channel/UCNDd2dOwC80m_2VdGPmwKDQ
💬 Share your thoughts on LinkedIn: https://www.linkedin.com/groups/18681043/

Explore the full features, setup guides, and advanced usage.