kiselitza
kiselitza on Hacker News
What's your use case? What are you looking for in an API tool?
I'm helping build https://voiden.md/
We just dropped a major beta, FOSSing it by the end of the year.
That's quite a list!
Have you by any chance stumbled upon Voiden thus far?
It just got a major beta release, and is aiming to open source in the following couple of weeks: https://voiden.md/beta
It's always the "it depends" kind of answer.
In bigger companies, you have teams dedicated to API governance, whatever they say, it's how it's done. In early-stage startups, you have full-stack folks doing end-to-end design, test, integrate with UI, document, etc. The trickiest ones are the ones that are in between these two stages. It's where it gets messy, and you MUST have something in place to serve as an API contract. Swagger dominates that, imho, Postman collections and docs are used a bit differently in my experience.
I'm helping build https://voiden.md which serves as a unified place for API spec, test, and documentation, but there are also plenty of API tools that focus solely on endpoint execution.
Hi, thx for the feedback!
Testing the settings (including different themes and font sizes as we speak).
Some tweaks are been made on the responses side as well.
As per the rest of your comments, some of these things have been discussed or touched upon, others have been just added to the discussion board :)
Hi! Thx for that.
Can you please open an issue with a screenshot here:
https://github.com/voidenhq/feedbackWhat you're saying doesn’t sound familiar whatsoever, but I'd really like to look more into it.
And yes.
It's completely free.
With plugin extensibility for anyone to build/install whatever they want.
The CEO committed to open-sourcing it, as well as to not monetize on anything that doesn't introduce operational costs to the team.
https://voiden.md/blog/why-we-rebuilt-bloated-api-tooling
Ah, yes, the cloud-dependent tool that forces you to pay per seat and log in for any type of collaboration is down when their cloud provider is.
Anyways, the folks have spoken, no need to double down.
There are more than a dozen alternatives to it, and new ones are coming up.
I'm helping build a new one.
- Completely offline.
- Gives the ability to build reusable blocks (headers, query params, etc)
- Let's you document everything in Markdown.
- Imports your collections and cURLs.
https://voiden.md/
I mean, IF the API is primarily tailored for UI presentation, there's already a text/html that you can use. I don't see the real problem here. Unless it's a type of API that has multiple purposes. In which case you got to tailor the response/presentation based on the needs.
Either way, the time needed to build a HTML elements will be eventually spent somewhere, on the server or on the client side. Server provides you with the data, you pick the form in which it is sent, and then work around the presentation layer.
I'm helping up the team behind https://voiden.md so I can tell you, it's easy to present the HTML even in the API clients, let alone the website itself.
A TL;DR of it is that for teams behind APIs, building, documenting, and testing APIs feels all over the place nowadays. It's a pain, it wastes time, causes errors, and frustrates everyone involved.
This post dives into why API tooling is such a headache, why the industry keeps making it worse, and how Voiden attempts to make life easier for developers.
Totally agree on this. There are things that belong in cloud, even a 3rd party one. Not everyone has a luxury of self-hosting. But keeping API secrets in any 3rd party cloud is just insane imho.
Working on it. It's hard to explain to devs who used to something how bad that something is. Especially when it once was awesome.
Something internal, or did you publish it?
What would you say is the most important stuff to you? Only simple API testing, or you gotta take care of the specing and documenting it as well.
Yep, sounds like that to me too.
Pay-per-seat works well when no proper competition to go against it.
What we built with http://voiden.md should be free forever, with monetization on plugins, but only the ones that introduce costs to the team.
The blessing was that the team was already profitable on another tool, and VC-independent, so nobody shoved some dumb design decisions down anyone's throat.
Posted by
kiselitza on Wednesday August 06, 2025 @02:54AM
from the self-post dept.
Just thinking out loud.If not for a gazillion other reasons, a recent outage from Postman should remind us again why proper design decisions matter in devtools.API workflows shouldn’t live in the cloud.
A LOT of devtools shouldn’t live in the cloud.
Some tools can’t work without it, all good.
But a whole lot of them are there just because of some poor design choices.Yet…- No cloud? No outage.-...
I mean, isn't that a good thing?
At least there won't be any security concerns during the outage. (:
People are just used ot it. Even with all the bloat. I'm helping up the http://voiden.md folks in an attempt to build an actual API devtool, not a tab+click API SaaS platform.
A quick guide on how to ditch bloated Postman collections and migrate to Voiden for a lightweight, code-first workflow in minutes.
Posted by
kiselitza on Thursday July 17, 2025 @08:05AM
from the ask-hn dept.
I'm working with a VC-independent team that is open-sourcing https://voiden.md in the following months. The goal is to try and foster community while avoiding traps where paid features limit freedom, or even to come off as potentially being just one more of those oss-as-a-strategy bait-and-switch companies.Now, the feature-limiting bit is IMHO taken care of. However, when it comes to licensing...
A helping hand to Ebiose AI here.
I’m super excited to see the project go open source.
There is already some literature about improving agents through the evolutionary process (not only AlphaEvolve). And others are talking about AIs that build other AIs, which is sometimes called ADAS, for Automatic Design of Agentic Systems.
We have already experienced this, notably on math problems.
But here, with the community, the goal is really to trigger the self-improving process.
The only way to do so is to challenge Ebiose with real use cases so that reusable agent components emerge organically and evolve over time.
TL;DR Voiden, a free, offline API workspace, decided to say no to SaaS "Teams" features because they're:
1) bloated,
2) expensive, and
3) break developer workflows.
Git is the real collaboration engine. It's free, familiar, and tied to your codebase.
Read more on the link in the title.
Posted by
kiselitza on Wednesday July 02, 2025 @09:52AM
from the voiden.md dept.
Much appreciate the feedback! Took it to the team already. I waited to get a confirmation for your question before answering, so here it is: it's built on top of tiptap + codemirror.
Beta Linux version is now on the website. Feel free to go check it out :)
Beta Linux version is up there. Feel free to check it out :)
You almost had me until the "5px font" line, then it just went into waffle territory.
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.
Atm just an F, catching up with the rest of the letters. :)
Much appreciate the suggestions! :)
Maybe you thought of an SDK-like client/wrapper for calling certain APIs, so it sounds natural to call it an API client?
Here you can check a list of currently OSS API clients (competitors to Voiden - the tool I posted about)
https://github.com/stepci/awesome-api-clients Will join the list soon after we go OSS too. :)
You could technically add mdsh to the Voiden terminal, and now the whole thing is fully markdown haha. Curious, what did you learn from exploring it?
Or maybe I'm the wrong storyteller for you :D
We did get a couple of pieces of feedback re- the landing page not being clear. I'm wondering if you checked the website before or after reading my copy? Would you say that may have impacted this "time to realisation" span?