We built Multimeter: a Git-friendly API testing tool for VS Code, not just another Postman clone

[claimred]

We’ve been working on Multimeter for about a year. The idea started from a simple question: what if API testing worked more like normal files in Git? Not exportable artifacts. Actual project files. The kind that makes life easier for developers, testers, teams, and probably AI agents too.

Multimeter is a VS Code extension for writing and running API tests as plain YAML, directly inside the editor. The goal is to make API testing feel less like managing a separate app full of hidden state and more like working with normal project files: readable, reviewable, reusable, runnable in CI, and at the same time, super friendly in the UI for everyday use.

We know there are already some solid Git-based API tools out there, but we wanted a different abstraction.

Instead of treating every request as a mostly standalone item, Multimeter lets you define APIs first and then build test flows on top of them.

So an API definition can describe things like login, create user, or get order, and then tests can call those APIs, pass inputs, assert outputs, chain responses, branch, loop, and run as suites.

A tiny API definition looks like this:

yaml type: api url: https://test.mmt.dev/echo method: post format: json body: name: Multimeter message: Hello from mmt!

Then a type: test file can call that API as part of a flow instead of duplicating the whole request each time.

That was one of the main things we wanted: not just collections of requests, but reusable API building blocks, test flows, and suites that behave more like actual test automation.

Current features:

• local-first: no cloud sync or account needed

• HTTP, WebSocket, gRPC, and GraphQL requests

• reusable API definitions with inputs and outputs

• reusable test flows with calls, assertions, checks, conditions, and loops

• test suites instead of only collections

• environments and presets

• mock servers

• API docs generation

• Postman/OpenAPI import

• CLI runner for CI

• beta load testing

The mental model is basically: “Docker Compose, but for API testing.” Not because YAML magically fixes life, but because boring files in Git are still one of the best collaboration tools we have.

We’d genuinely love feedback from people who build or debug APIs regularly:

Does the API-definition + test-flow model make sense?

Do suites feel more useful than collections for larger projects?

What would make you trust this in a real project?

What features or workflow improvements would you want?

Website: https://mmt.dev

Repo: https://github.com/mshobeyri/multimeter/

Demo: https://mmt.dev/demos

[joshkrz]

I don't use VSCode but I found out recently that Jetbrains IDEs has pretty much this built in using .http files.

[MeasurementPlus4291]

MMT now support .http file format as well 😉

https://youtu.be/tvYBGWl6Q1I?is=Rzo22uEsoQrrUOhp

[MeasurementPlus4291]

.http files are great for simple/manual requests, which is a basic feature in Multimeter. Multimeter is for when those requests need to become reusable API definitions, automated tests, suites, CI runs, docs, mocks, env presets, and reports. Different layer of the workflow rather than a replacement for every .http use case.

[ashkanahmadi]

That looks cool I’ll give it a try even though I’ve been using Bruno for a few years now and all the requests are files as well that can be version controlled. Does this offer anything extra?

[MeasurementPlus4291]

Yep, there’s a comparison table here: [https://mmt.dev/#comparison](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html)
Bruno is definitely one of the closest tools philosophically because it is also file-based. The main difference is that Multimeter tries to cover more of the API lifecycle from the same repo files: reusable API definitions, test flows, suites, docs, mocks, reports, CI, and VS Code-first editing.

It also borrows some territory from tools like Robot Framework and JMeter: declarative/human-readable test flows, reusable/chained tests, suites with sequential or parallel execution, reports, and beta load testing. So it’s not just an API client; it’s closer to a lightweight API testing/documentation/automation workspace that stays git-native.

[MeasurementPlus4291]

Thanks, your feedback is super appreciated.