Link: https://github.com/VoidenHQ/voiden

Voiden is an offline-first, git-native API tool built on Markdown
Voiden is an API client we have been building that takes a different approach from most existing tools.

It didn’t start with the idea of “building a better Postman”.

A bit of background. Over time, API tooling has become heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you are offline. On top of that, time wasted on fixing API specs that don't match the code, docs in separate random tools, tests also separate and an overall governance mess. Not to mention collaboration.

So we asked a simple question: What if an API tool respected how developers already work?

That led to a few core ideas:

• Offline-first , no accounts, no telemetry
• Git as the source of truth.
• Plain text files: specs, tests, and documentation live together in Markdown
• A programmable interface instead of static forms: requests are composed from reusable blocks (endpoints, headers, auth, params, bodies, etc.) that you can structure the way you want
• Plugin system for extending functionality rather than bloating the core with new features
  Some of our core plugins include gRPC,GraphQL,WebSockets,etc..

We have just also updated our docs to welcome community plugins, so teams can extend the tool for their own workflows or integrations. https://docs.voiden.md/docs/plugins/build-a-plugin

We opensourced Voiden because extensibility without openness just shifts the bottleneck.
If (API) workflows should be transparent, the tools should be too.

Welcome to try out and share feedback- happy to chat with everyone.

Strong opinions are encouraged. :)

Github : https://github.com/VoidenHQ/voiden

Download here : https://voiden.md/download

Cool, I use Bruno, but it's always nice to have an alternative. I'll keep an eye on it.

Postman.i2p?

For context, I looked Bruno up

Bruno is a Git-friendly and offline-first open-source API client aimed at revolutionizing the status quo represented by tools like Postman and Insomnia.

Voiden lists Bruno on their comparison page as well

What about Yaak? I was using it before AI started creeping in, but seems to be the same with all of them.

I don't see why I would use this instead of vim. I see that you think it's a different approach, but it looks like a fairly standard rich-text editor to me; what am I missing?

Yaak has some ideas and concepts that I like a lot. One thing that is similar with Voiden is that they are extensible through plugins. This way the core can stay lean and new functionality can be added up without bloating the app.

Played around with it. I love the idea and it's already pretty usable. It needs some QoL tweaks (allow resizing response window, add visible scrollbar, small stuff like that). Moving away from postman to this for work.

Hey :) Voiden is not a rich text editor (non offense to rich text editors). It is executable API docs: requests, docs, and explanations that all live in Markdown… and actually run. (Yes, your docs that do stuff). As far as I know it is the first tool to collapse design, testing, and documentation into one file, one format, one workflow. If you know another tool that does this, I genuinely want to hear about it (definitely not trying to be cocky, just curious :)

yay - feel free to add few of these QoL tweaks here: https://github.com/VoidenHQ/voiden/issues

like @Corbin@programming.dev said, except I don't see why I'd use this instead of .http files. They're pretty much exactly what you've done here, but an actual standard on reusable text files for postman like calls.

• Visual Studio support
• Jetbrains
• VSCode
• or even from the command line

They're literally just files that follow the RFC 9110: HTTP Semantics so they'll never be out of date, there's no need to keep them in sync with anything, you can keep them directly alongside your codebase, even alongside whatever api endpoints you're testing.

You can even use plugins that make it more interactive like this one (I've never used that product so I'm not saying it's good, just that stuff like this exists)

There is rswag which produces openAPI specification files directly from test runs. But of course its mainly working with Ruby (on Rails) and RSpec.

I like the idea of Voiden!

Seems similar to Jupyter/Polyglot Notebooks, but focused on APIs.

awesome, thanks for sharing.

feel free to play around and tell me what you thought - especially around the reusable blocks: most devs we talk with consider this to be the most "different" thing and what is more different than other clients.. For me its this one too + the plain text files all the way from specs, tests, docs, context etc...

This is actually a great comparison ! Thanks for these words !

Hey, that’s a fair comparison. .http files are actually one of the closest things conceptually.

The difference is mostly in how far the idea is pushed.

.http files are basically request definitions written in HTTP syntax. They are great for sending requests and keeping them next to your code.

Voiden treats the Markdown file more like an executable API workspace. Requests are composed from reusable blocks (endpoints, auth, headers, params, bodies, etc.), so instead of copying similar requests around you can structure them like small building blocks and reuse them across the file. That becomes useful once an API grows and you start repeating the same pieces everywhere.

Another difference is that the file can mix documentation, explanation, requests, tests, and scripts in the same place and actually run them. The goal is that the file itself becomes the living artifact of the API workflow rather than just a request list.
And since everything is still plain text and Git-friendly, you can keep it alongside the codebase the same way you would with .http.

If someone is happy with .http files they probably don’t need Voiden. The idea is more for teams that want the requests, tests, and docs to live together in one executable spec rather than spread across tools.

Do you use .http mostly for quick testing, or do you keep full API workflows in them?