Show HN: Voiden – a free, offline, Git-native API Client
Voiden is a free, offline, Git-native API client. Your API definitions, docs, and tests all live together.
It came out of years of frustration: cloud sync lock-in, paywalled basics, bloated UIs, and lag on even simple requests. So the team built the opposite: an offline tool with no login, no telemetry, no lock-in. Just markdown and hotkeys.
It behaves like code: local files, git branches, no cloud nonsense. Terminal is built-in, so you can commit, diff, and push changes right from the app.
Docs stay close to your requests, so that API spec and what the API actually does never drift apart. No more scattered Postman, docs, and test files everywhere. A single source of truth.
A minimalist GET request looks something like this:
GET
https://dummyjson.com/posts
Not OSS (yet), but 100% local and free. Optional plugins will be coming down the line, but the core stays free.
We'd love feedback from folks tired of overcomplicated and bloated API tooling.
Instead of saying what it is, say what it does (for the user). For example instead of 'Offline-first API Client'..., try "Document your API, test it, and version it using Git 100% locally and free in a modern GUI. Voiden even includes a terminal so you can execute any command or custom workflow without ever leaving the app. (OSS release coming soon)". Remember, show, dontt tell.
Does the "yet" infer that you do intend to open source the baseline product, and then have paid plugins?
Voiden evolved from an internal tool where the team bundled a lot of features into the core product. Currently separating certain things into plugins. By the time that is done, and some community adoption/engagement is happening, the tool will be open-sourced.
As per the plugins, that's right. Some of the plugins can/will be monetized - but that's the discretion of the plugin developers. We won't be charging for any plugins that we build, unless they have an operational cost for us.
It's not unheard of. For instance, I got another team and devtool I work with, non-related to the API niche, and they are going open source mid-next week. Some teams want to build the core their way, some want to see if it will catch traction before committing to support an entire community and contributions, some have got something else going on, some actually ARE shady and talk OSS for clout, etc.
1. I would really like a way to run the endpoint by clicking something in addition to command+enter (it wasn't obvious that I could open the sidebar and then click play but I see that now)
2. It would be good to include the evaluated request body and headers in the result sidebar
3. Duplicate file in the file tree context menu - I saw it in the tab context menu but that seems unintuitive
4. Maybe allow the user to set variables inside the markdown that can be imported to other files, for example a customerId variable that different requests could use which isn't part of the environment
5. Dragging text around appears like it will be moved but when releasing the mouse nothing happens
And finally 1 question I have: is this using an underlying text editor? It looks pretty robust but it doesn't look like VSCode, maybe something else? I am wondering if it's available to use for my own project
Is the goal of the project to let people write documentation for APIs, explore APIs, or something else?
Here are a few suggestions:
1. Start with a clear story of why you built this. Not lock in etc, but what were you or your team trying to do? That will help me understand whether I too try to do this thing.
2. Now you can tell me about all your frustrations, and I as a fellow misery drenched individual will say "Yes! I too have suffered the lack of cloud sync lock-in!"
3. Let me see it! Is there a way to embed the actual editor in the browser? Barring that putting a heading over the video, or a caption telling us what you're doing. When I click around to explore, let me click on those screenshots so I can see what you've built.
All in all, this looks really neat, but the challenge with building something divergent is that you need to invest more effort in telling the story.
If you're a dev, and you excessively ran APIs or governed them, you most likely remembered the pains mentioned later in the post the second you came to "API client" bit. The frustration bit should tell you why it's not just another one of those tools but rather addresses those pains. And the example is showcasing the minimum effort needed to execute an endpoint.
If I were to rewrite it again, I don't think I'd change much, if anything.
I am a dev, and it took me a while to realize this was the pain point you were solving. Mayhaps I'm the wrong dev, and that's just fine, regardless this looks pretty neat.
Not sure, it's hard to parse your website. Too many empty taglines like "docs that do more" and "git-native", and the 5px font in your screenshots does not help. This screams "no programmers only designers here". Honestly it's a red flag for a programming tool.
As for the Hurl comparison: that’s like saying Hurl is the same as Bruno, Yaak, and the rest of the crew - if aiming there, sure. Voiden isn’t a themed CLI, so visually it’s not even in the same category. And functionally, the whole point is having docs, tests, and the spec all in one place. That's something CLI tools don’t really aim to solve.
Some overlap in request-sending, sure, but very different purposes.
Yes I would say presenting your software with tiny full-screen screenshots of your IDE where you can barely see the code, rather than code snippets, is very telling. I can right click them and "open image in new tab", but that is the only way to get a sense of the program from the "features" page, other than the GIF on the landing page.
Compare with the Hurl landing page, I immediately know what this does and how it's used: https://hurl.dev/
It's refreshing to see a new API client that isn't just a reimplementation of Postman's interface.
I think it'd be useful to focus on this more:
> Voiden turns your API definitions and docs into dynamic, purpose-built interfaces — no fixed UI, no rigid templates. Everything is composed in one place and rendered down to Markdown, tailored to the API it serves.
Curious, how do you feel about the tagline stuff? Happy to learn anything else you'd be willing to add here. We're all for making it crystal clear, no fluff, just making devs lives easier, which also means not wasting their time to understand whether they need it or not.
It seems to be some kind of wysiwyg editor? With elements specific to API docs?
But then why does that make it an "API client". I'm guessing "API" specifically means HTTP API here. But "client" is completely throwing me. An API client is just software that talks to an API. So what's with the wysiwyg stuff?
Is it something like Jupyter notebooks?
By definition, API Client is a devtool that makes it easier for devs (& co.) to design, test, document, and debug APIs. If it's confusing, we can take it to Postman, but it's an industry standard, been that way for a long while.
That's not the definition of "API client" I'm familiar with. In fact it feels like a very specific definition of "API client" - which is a broad term that I am familiar with.
(Why does it sometimes feel like I am not getting the memos that everyone else is getting? It's like when a new job description for an old job suddenly appears and everyone pretends that what it's always been called!)
There are tools like Jupyter notebooks that have all the functionalities, but their file format isn't very readable or diffable using standard terminal tools.
A while back I wrote https://github.com/zimbatm/mdsh to explore the space. Voiden.md looks like a fancier version of that.
When do you think you'll have a linux client available? I'm hoping it will be available via flatpak :)
Shouldn't take long until Linux is up there, tho. I know the team started managing the build process.
It's nice to have the option to not need an entire online apparatus to make your software function.
If you're designing your own API, you can do all the specs, docs, and if you get it up and running on localhost, you don't even need internet for testing it.
If you want to run a hosted API endpoint, or push your changes to git ofc you'll need the internet, but not because of the application, rather because you're trying to access something else that is not offline.
Or you're asking me something else?