Voiden is an offline-first, git-native API tool built on Markdown - and it very intentionally didn’t start as “let’s build a better Postman”.
Over time, API tooling became heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you’re offline. Testing a localhost API shouldn’t need an internet connection.
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
-
Specs, tests, and docs living together in Markdown
We opensourced Voiden because extensibility without openness just shifts the bottleneck.
If workflows should be transparent, the tool should be too.
Github : https://github.com/VoidenHQ/voiden
Download here : https://voiden.md/download
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)!
Free Software I notice, which is always nice to see.
yes :) welcome to try
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.
Postman never appealed me for these exact reasons, and I usually just use curl, but this looks like a great option.
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
welcome to try and share your feedback here or here: https://github.com/VoidenHQ/voiden :)
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.
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!



