Nord.pubVoiden - A Markdown based Open Source Alternative to Postman
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
Share on Mastodon
Share on Reddit
Share on WhatsApp88 Comments
Comments from other communities
i’ve been looking for a silver bullet in this space. hurl[1] seems promising as well. i feel like Bruno has always been jank, and going 1.0 didn’t help. at work i’ve stuck to vibe coding my API test code with a stack of TOML configs, that way i get to reuse/test my client code as well.
what i want is something version controllable with lightweight dependencies that i can automate easily. i’m afraid that discounts this project. not going to ask my team to download Yet Another Electron API client UI. i’m hesitant to introduce hurl, which can at least be scripted.
hey, nikolas here (part of the team of Voiden)- I am keen to understand more if you dont mind. Which of the preferences you mentioned discounts this project? the version control and lightweight?
I guess you are you referring to the tool being on Electron (Since the version control is handled through the native git integration)?
We used electron cause allows to deliver the same experience across Windows, macOS, and Linux, and makes it easier to iterate quickly in these early stages.
a few points:
Some apps do feel heavy because of how they are structured : monolithic cores, always-on cloud layers, or unnecessary background services. Voiden is (intentionally) built with a lightweight core: offline-first, Git-native, and without extra baggage.
Voiden uses a plugin architecture. This means that we have a small core and all the extra functionality is optional (users can enable or disable plugins) so the base app stays small while the ecosystem can grow. Community contributions or advanced features don’t inflate the core, they live in plugins that users opt into.
At the same time, there is no special tie to Electron :) We evaluated other options as well but we felt they didn’t offer the same support for all the features we wanted to deliver.
But we intentionally designed the plugin SDK to be framework-agnostic, leaving the door open to switch the core to a different framework in the future if it makes sense.The goal is a tool that stays lean, extensible, and adaptable as it evolves.
apologies for the long answer - hope it makes sense?
first, i’m biased. i’m a home row kind of guy. i live in the terminal.
Which of the preferences you mentioned discounts this project?
i’ll be direct: light weight dependencies. i understand why you’d use Electron to build a UI, but does an API tester need a UI as a first class feature? i think something like hurl shows it’s not necessary. i get that maybe it’s an accessibility problem (juniors and Java devs being afraid of the command line etc), but UIs are not composable. i could run hurl (or curl for that matter) via bash or nushell or Elisp or Rust or Powershell or JavaScript or GitHub Actions or as a k8s postDeploy… and, not to draw the ire of Lemmy armchair zealots, they’re not easily usable by agents. an 8B model on my Macbook could figure out hurl, no MCP or crazy preprompting required.
plus: user adoption. this is the self hosted community, so maybe not everyone here has the same concern, but i can’t just commit a bunch of exotic files to my shared repositories. Bruno was a tough adoption, even though it seems obvious to version control this stuff and it was the only real option at the time. now i’m tired of Bruno cuz it goes out of date cuz it’s not easily scriptable with our internal auth services because it runs everything in its bespoke UI. if they haven’t made a button for it, you can’t do it. that’s the problem with UI dev tools.
no shade, i understand some people would be totally lost if their IDE didn’t have a big green run button.
I actually agree with most of your premise.
Voiden is not coming from “people are too scared of the terminal, let’s save them with buttons.” It comes from almost the opposite direction. A lot of us are terminal people too. The problem is not that curl, hurl, scripts, OpenAPI, or plain code are bad. The problem is that API work tends to get fragmented across too many places once it becomes real.
You have raw requests in one place, auth logic in another, docs somewhere else, examples in Slack, test cases somewhere else again, and then different teams consuming different versions of what is supposedly the same API. That’s the mess we care about.
So the goal with Voiden is not to replace power-user workflows but to give them a better structure, while also making that same source of truth usable by the rest of the team, including people who are not living in the terminal all day, or simply have different preferences.
That is also why composability matters so much to us. Reusable headers, auth, query params, payload fragments, shared blocks, documentation alongside execution , not because curl cannot do requests, but mainly because nobody wants to maintain the same slightly different request 100 times across scripts, docs, and collections.
And on the “UI tools become dead ends” point: yes, that is the trap we are trying to avoid. We do not want a bespoke black-box UI where if there is no button, you are stuck. The idea is to have one source of truth that can still work for power users, can be versioned in Git, can be shared, can be documented properly, and can evolve into automation/CLI/agent workflows as well.
So from my side it is not “UI versus terminal.” That debate is honestly a bit too small. What if we reframe this to: “Can we have one composable, reviewable, reusable representation of API work that serves both the terminal-native people and the wider team without duplicating everything across five tools?”
That is basically the whole bet.
So yeah, I get the skepticism. I have it too. The world does not need another glossy “API client” that turns into a toy the moment you step outside the happy path.
The point of Voiden is precisely to avoid that fate. I am sure you will see how radically different Voiden’s take is, if you just give it a spin for a few mins. In a world full of postman clones - we want Voiden to really stand out with a different approach to api tooling. :)
One thing your answer dodges is the automation part. Do you plan on offering a cli to run individual workflows/scenarios? The UI is awesome for building and maintaining the workflows, but if I want to use them for automated testing for example I need to be able to run them headless.
The one of the most important features - I see thats not mentioned by the author of the post here - even though it should be super highlighted - Voiden is the first client where the entire api request is deconstructed into reusable blocks.
Headers, Query Params, Path Params, Body (JSON, Form params etc)..
and reuse them in different apis to have ALL common elements done in one file and then change them once and it will all get updated in all the other docs (just like in code - when we add a extra logic to an imported method). thats super super convenient and saves so much time compared to all the other tools out there - where you mainly duplicate stuff or just use environment variables to substitute.
OH and the pre and post request scripts - with the support for different languages like JS, python etc .. its amazing.. first API client i use where you can write pre and post api requests in a different language than JS (as a non JS developer this is huge)!
Mugita SokioFree Software I notice, which is always nice to see.
Gave it a quick shot right now, and gonna be honest - while the premise seems nice, the sample project is very transparently AI slop generated with a prompt that, I can only assume, included an instruction like “for every sentence that doesn’t include a whimsical quip, I’m gonna kill a kitten”. It is absolutely grating to read. I don’t care if you do that in your marketing copy, but keep that shit out of technical documentation, it’s annoying, it’s distracting, and it’s turning me off the entire project. Like wtf is this:
we are indeed looking at the docs again. To begin with we focused on the tool itself so some of the examples that you see can indeed be worth revisiting and re writing. :) But I hope you can focus and zoom in to the tool itself and see how this can help you with your API workflows.
Deleted by moderator
yap, I think the plain text all the way from design, tests and docs is powerful. Looking forward to any thoughts you might have when you try.
It’s 2026, and we’re still essentially filling in the same request forms from almost two decades ago. Headers table. Params table. Body tab. Raw/JSON toggle. Postman’s surrounding ecosystem grew. The pricing model evolved. The cloud story expanded. But the core interaction model barely changed.
For a company that once redefined API tooling, I feel they dropped the ball in innovating the hell out when they had the chance. Now they are burdened by their own success - cant move and cant adapt. Only squeeze people for more.
And maybe the bigger impact, sadly of Postman, is what happened to the ecosystem. Because Postman defined the category so strongly, most competitors copied it. For years, innovation in API tooling meant “Postman, but open-source” or “Postman, but git-based.” The dominant UX pattern became the ceiling. Everyone optimized to replace it - few tried to rethink it.
And I think thats where I see tools like Voiden as a breath of fresh air - a modern take, composable blocks, programmable interfaces. I love it. I dont want to be clicking 100 buttons to figure out whats in my api “tab”. :D
All of that when I can just keep using emacs’ restclient.
Emacs is not that hard. You can learn Emacs in one day, every day!
I’ve been enjoying verb.
quite cool - i think voiden is similar in premise to verb - but it is more easier to manage for non emacs folks. But i’ll check it out - emcas will bring back the ptsd from my phd days of writing my thesis on it :D
I really think tools like voiden, hurl, and verb make sense. They make it easier to troubleshoot a system later or to share requests with other developers without leaving the repo. The only real challenge becomes handling authentication scenarios without putting secrets in plain text.
Speaking of writing a thesis, I imagine that leaves plenty of room for PTSD! I personally like the direnv support for emacs much more than other environments, and I’ve become a big fan of ripgrep and fuzzy finding.
Wow, an org mode rest client; this might be worth switching to! What I like about these is that you end up with documentation in a standard file that can live along with your APIs. Org mode can of course be saved either as org files, or exported as any number of things - whatever your team uses. Ok, time to go bully some vim users.
Daniel Quinn
ReginaPhalangeHate this elitist shit.
Just for once try to work with other humans on a tech project that requires collaboration.
Postman strike a balance between technical and user friendly.
RTFM for curl for everyone is alienating for a a lot of people.
I’m liking seeing both these opinions side by side. Both sound great.
Someone wants to spoon feed me curl commands, like thanks :-)
Someone wants to spoon me a UI which I can’t curl, thanks eh :-)
Or for a more purpose built wrapper (for the same use cases as postman): https://hurl.dev/
curl is great. I use curl. Most developers use curl. But “you can call an API with curl” and “curl is enough as an API working environment” are two very different claims.
The problem is that real API work is almost never just one request typed into a terminal like some kind of beautifully minimalist Unix haiku. It usually turns into auth, environments, copied headers, reused payload fragments, request chains, documentation, testing, debugging, sharing examples with teammates, reviewing changes in Git, and trying not to break prod because you forgot to swap one token or one base URL.
At that point, people are not really using “just curl” anymore. They are using curl plus shell scripts, plus notes, plus env files, plus copied commands from Slack, plus random JSON files, plus tribal knowledge. Which is fine, until it becomes annoying, fragile, and weirdly hard to collaborate around.
That is the gap Voiden is trying to solve.
So for me it is not “curl vs Voiden.” curl is a low-level execution tool. Voiden is a workspace for actual API work: writing requests, organizing them, reusing pieces, documenting them, testing them, versioning them in Git, and not duplicating the same headers/body/auth setup 45 times like a person slowly losing control of their life.
Why use curl when you can use netcat? I love curl but curl is not postman alternative.
Why use netcat when you can just tap the bits into an ethernet cable with a bench power supply like a telegram operator?
T4V0Cool, I use Bruno, but it’s always nice to have an alternative. I’ll keep an eye on it.
KissakiFor 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.
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.
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.
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)
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?
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?
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 :)
LeFrogThere 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!
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…
NostraDavidJust learn and use curl instead - I don’t think it will ever get paywalled.
boredsquirrel (he)How does this compare to Bruno?
Voiden’s core request model is based on composable blocks (for elements like headers and auth) that are reusable across requests for a DRY (Don’t Repeat Yourself) approach, unlike Bruno which treats the request as a single, monolithic object that leads to copy-pasting and maintenance burden.
For documentation, Voiden provides living documentation by integrating runnable requests and human explanations side-by-side in the same Markdown file, ensuring it stays in sync with the API, while other tools’ documentation is often separate.
From the monetisation side Voiden: Is an open-source community infrastructure project backed by a different main business, reducing the pressure to monetize aggressively. Bruno is as an open-source project that is under pressure to find a viable monetization strategy, which can lead to license shifts or paywalls.
You can read about the comparison here : https://voiden.md/comparison
depends on what you want to focus on - for example I like the reusable blocks and the programmable interface + the idea of community plugins that extend the tool!
So you basically made org-mode + restclient for people who don’t use Emacs?
That’s a pretty good comparison.
The core idea of executable documentation next to your code is exactly what we were aiming for.
The difference is that Voiden is a dedicated, cross-platform app for the modern ecosystem, bringing the power of that file-centric workflow to everyone. We specifically go further by offering resuable composable blocks for requests (closer to functions than monolithic objects), a unified toolchain for design, testing, and documentation, and a clean, Git-native experience for all developers.
The core idea of executable documentation next to your code is exactly what we were aiming for.
Do you need to use the electron app, or could you for example directly eval a source block from the editor?
Ek-Hou-Van-BraaiThanks for sharing, I’ll give it a try
Postman […] offers a proprietary API platform for developers to design, build, test, and collaborate on APIs.
Ok? Guess i’m too out of the loop. But thanks regardless.
Edit: mixed the explicit “proprietary” from the german Wikipedia in the quote.
Just as I was getting fed up with Postman. I’ll be looking into this.
TomasEkeliThis looks interesting, but I don’t particularly want another client app for this when we can “just use curl” and have that in files (already very git-friendly)?
This will not help many, but I’ve found a good way that helps me and my team, since we’re all in VSCode most of the time anyway. The extension “REST client” lets us write HTTP calls directly in a file and run them from there, with some basic variables and support for different kinds of authentication scheme and environment variables. It has replaced POSTman and Bruno for us: https://marketplace.visualstudio.com/items?itemName=humao.rest-client
If you’re not already using a vscode based IDE this won’t help you at all, sure. But, if you are - this lets you write up sequences of requests in a (still manual, but quite quick) file to test APIs and play with them. Highly recommended!
Oh nice! gRPC support as well. Perfect find the day after Yaak started crapping out on me.
Welcome to join us here : https://discord.com/invite/XSYCf7JF4F
ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86
All of those explanations, but you’re not even saying WHY it’s an alternative, or to WHAT
Its an alternative to Monolithic Requests - Voiden has composable blocks which are an alternative to copy pasting entire request objects. We do not lock in collections in cloud like other api clients like postman and have a file centric and git native approach. Also we offer a unified toolchain - for design, testing, and documentation as an alternative to juggling multiple disconnected apps.