kiselitza

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/feedback

What 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'm helping build Voiden: https://voiden.md But am thinking of a LOT these days, really, saw a bunch of interesting APIs on https://apyhub.com/catalog recently, so might go on and tackle a few of these.

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.

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.

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.

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?

I've been reading this one and then the post itself a couple of times. Appreciate the suggestions and the time you took to write them down. Just not sure if those would help here (not saying they 100% wouldn't). I am all for storytelling on some platforms, but HN is IMHO a no-bs, no fluff, keep-it-short and to-the-point space.

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.

The Jupyter comparison isn't completely off base if you'd like to rationalise it that way. Similarity would be blending the code and the docs in a single file, where you can then also execute something.

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.

It's an expression. Meaning it's not just allowing you to use some git sync workaround, but actually use it as if you would in your terminal, respecting all of its commands and conventions.