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

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

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

Hey there,

A few months ago we open sourced Voiden, an offline API client we originally built to replace Postman internally.

Voiden now has around 11k installs and growing every day. ❤️

Core principles we built it on:

• free and local-first
• file-based, all plain executable markdown
• composable through blocks
• collaboration in Git, where devs are working already

The main thing is that in Voiden, API requests are not (static) forms. They are built from blocks (endpoint, auth, params, body) that can be used, reused, replaced and version in Git, just like code. And all that in plain executable text.

Our inspiration:

Our inspiration was curl, and how simple it is, and obsidian, because of how powerful it can be.

Who this is for:

Developers, QA, Technical Writers working and collaborating on APIs.

Progress:

Since open sourcing, almost everything that we shipped came from actual users, feedback and contributions that pushed the tool in a few interesting directions. You can check our change-log here: https://voiden.md/changelog

A few highlights:

• Composable API workflows: Voiden lets you build reusable .void files that can be combined into flows, run multiple requests in sequence, and use real scripting (JS/Python/Shell) before and after requests.
• Added a “skills” layer so tools like Claude/Codex can operate directly on .void files and request blocks.
• We added an SDK for community plugins.
• & more...

Feedback:

This project is now mostly shaped and driven by community ideas and contributions. Welcome to join and help us make this even more awesome.

There is no account setup, its free and totally offline.

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

Download: https://voiden.md/download

Went through a competitor's stargazers. Most of them aren't real.

I open sourced an API IDE this year. Same space as Postman, Insomnia and the rest, but at the same time nothing like them: everything is plain text files in your repo, offline, no account etc.

One of the first things I thought and cared about in the early days was of course downloads and installs. And secondarily, it was stars.

And yeah, some of the competitors (that are also open source) have star counts I envied.

And we didnt do bad, we got 1000 stars relatively easily, with the first launches, rollouts. Developers seem to love what we are doing (the fact that we are not trying to clone Postman and make sth unique instead).

Recently I did the grubby founder thing and opened a competitor's stargazers list (one of the big ones). Partly curiosity, partly hoping to find some users or emails to reach out to. Not proud of it but ok, I was just curious to see who are the users.

Except there were almost no people in there.

Accounts a few months old. Zero repos or one fork. No activity. Multiple usernames like 4145243@ere.com. Public emails that were pure gibberish. Pages and pages of this.

How did this happen? : either they bought stars , or bot farms starred them to make the bots themselves look legit. I

In the beginning I was looking up to the stars but it seems they are as about as real as Instagram followers in 2015.

The only thing my outreach scheme found: the audience I was envying might not exist.

p.s. here is the repo of my tool , in case you wanna have a look.

https://github.com/VoidenHQ/voiden (yeah we have 1272 stars right now and they are all actual devs :)

Hey there,

A few months ago we open sourced Voiden, an offline API client we originally built to replace Postman for us internally. Main inspiration was curl and Obsidian (and other plain text editors).

It now has around 11k installs so quite happy with this.

Core principles we built it on:

• file-based, all plain executable markdown
• API requests composable through blocks (endpoint, auth, params, body) that can be used, reused, replaced and version in Git, just like code.
• free, local-first, Git based

Since open sourcing, almost everything that we shipped came from actual users, feedback and contributions.

A few examples was building API workflows (multiple requests in the same file, for example for CRUD flows) and scripting (JS/Python/Shell) before and after requests. Also added a “skills” layer so tools like Claude/Codex can operate directly on .void files and request blocks.

Repo: https://github.com/VoidenHQ/voiden Download: https://voiden.md/download

What I am looking/hoping for:

• Feedback on the tool itself, especially if you design and test APIs in your work.
• Ideas and tips from experienced folks on how to improve the visibility of the repo, especially for potential contributors that are looking for projects to contribute on: Adding good first issues, or other labels? (currently not doing that extensively so I am planning to put some structure).

thanks a million, (this is my first post about this in this sub-lemmy, if you are in other ones you might have seen this already)

cheers,

Been building Voiden, an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either.

Made it intially available for Windows and Mac, but after getting requests from folks who work on Linux, we added Linux support a few months ago, before open-sourcing it. (That's actually one of the reasons we picked electron :to be able to ship fast and have cross platform consistency across Linux, Mac and Windows.)

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

So far, Voiden is available on Linux via:

• .deb for Ubuntu and Debian-based distros .rpm for Fedora, RHEL, and other RPM-based distros
• .AppImage for a portable option that should work across most distributions
• .AUR package for Arch users : https://aur.archlinux.org/packages/voiden-beta-appimage

Definitely considering adding more like Nix or Flatpak, but we are working to get our priorities right: Which ones would you actually use and prefer?

A disclaimer about the tool: Since we didn't want to build yet another (cheaper) clone of Postman, Voiden looks and feels very different:

• The UI is "programmable": Requests are “built” with slash commands from blocks (endpoints, headers, auth, params, bodies, etc.), like LEGO blocks but for API components. Or like Notion for APIs.

• These blocks can be also reused in different APIs to have ALL common elements done in one single file. You can then change them once and it will all get updated in all the other docs. Just like in code when we add an extra logic to an imported method. (In other API clients you would need to duplicate stuff or just use environment variables to substitute.)

• API Specs, tests, and docs live together in executable Markdown.

Welcome to try it out and let us know: what works, what breaks, and which packaging or distro support would make Voiden easiest for you?

Strong opinions are encouraged. :)

Github : https://github.com/VoidenHQ/voiden Download here : https://voiden.md/download

Git native, No login, No accounts, No telemetry.

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