nikolasdimi

I am a member of a + 30 people team and most API clients we used felt like they were built for a different job than what we actually did (testing endpoints, maintaining API docs and making sure that new versions of the API matches with out docs). Our team lives in Git, and our docs always drift away from the actual requests inside Postman. The fear I kept hearing when discussing with the team and other devs was "I don't need another bloated API tool".

So we built and open sourced Voiden a few months ago: an offline API tool where requests live as executable markdown and are versioned in Git.

The original idea and inspiration is to combine the flexibility of Obsidian-style files with the simplicity of curl. The result is a tool in which everything can be composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across executable markdown files.

Results so far: Since open sourcing, we got +12K installs, +1K stars on guthub plus a lot of feedback and contributions.

What it does today:

• REST, GraphQL, gRPC, WebSockets (as plugins, install only what you need)
• Ability to compose Requests with API blocks. Reuse, Replace & Version everything just like code.
• Postman and OpenAPI import so you don't redo years of work Built-in terminal
• Pre/post request scripting in JS, Python or Shell
• A batch runner for chaining .void files with env selection and stop-on-failure
• Agent-friendly CLI, works with Claude and Codex skills
• We have also a few features in early access, such as the (much anticipated) CLI runner +more

Looking for feedback and ideas from anyone interested.

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

Download: https://voiden.md/download

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.

hey there,

There is always a temptation to add "something AI" in new tools. Especially to tools that are somehow related to developer productivity.

At the same time I wanted to avoid this temptation with Voiden. So there is currently nothing screaming "AI" in it even though I can potentially see many many use cases.

This is also one of the main reasons I think that a plugin architecture is best. What was actually in my mind is that not adding AI is ok for now and the community will start coming up and building AI plugins. For example creating docs from specs and vice versa.

Any other use cases you can think that could be applicable to a tool like this? (Dev Tool with executable markdown files for API specs, tests and docs). The first plugins we shipped were more around methods (grpc, graph ql, web sockets etc etc).

repo: https://github.com/VoidenHQ/feedback

fuck you, no way!

this my take on a matisse painting, that you can find here.

https://www.clickatlife.gr/fu/p/228858/1200/10000/00000000005fd2d3/1/matisse.jpg

I thought of an idea: take your pencil and make your version this :) will be funny to see how different people translate this.

One of the things I discovered (or better said, something I suspected but had the chance to verify) while working on open-sourcing a tool (and API client tool): there is a big (mostly justified) trust deficiency out there .

I could feel it immediately in every discussion: always that little question in the back of people’s minds:

"Will this project "stay true", or will it change the rules on me later?"

We have seen this pattern repeatedly: Terraform > OpenTofu, Redis > Valkey, Elastic > OpenSearch....

I understand this: it’s becoming hard not to become a little cynical. In some ways, SaaS starts to feel better only because its more honest and at least the incentives and motivations are explicit from day one.

But why does this happen?

One answer is simple: bad intentions, that yeah, they do exist some times. But then this might be an oversimplification.

One aspect that is not often talked about: Many of the most durable open-source tools and frameworks (VS Code, React, Kubernetes, and Backstage among others) were built by companies where the tool itself was NOT the primary revenue engine. Their core business lived elsewhere.

This means that these tools could function as ecosystem infrastructure rather than direct monetization vehicles. They could stay open because they weren’t carrying payroll, sales targets, and investor expectations on their own.

In contrast, when an open-source project becomes the business, the incentives start to shift. The tool now has to "fund" teams, meet SLAs, satisfy investors, and deliver predictable growth.

Over time, that pressure often leads to open-core models, licensing changes, community forks, and growing tension between "community" and "enterprise."

So yeah, the intentions might have not been alway bad....but the economics have spoken...

The "open source first, monetize later" strategy feels super risky.

Once adoption takes off and the tool becomes central to a company’s survival, teams are forced into trade-offs that often erode trust and fragment communities.

My opinion is that Open Source thrives most easily when it IS NOT carrying the full weight of corporate survival.

When it is, preserving its original spirit becomes much harder.

If we want healthier developer ecosystems, we need to be more honest from the start. This means to either build an open-source project as genuine long-term infrastructure and commit to keeping it open, or build a commercial product with a clear monetization model from day one.

Both paths are valid. Trying to blur the two is what repeatedly leads to broken trust (with developers), frustrated contributors, and fragmented communities.

The takeaway? I guess it is that we just need to be upfront:

If your project is commercial lets be upfront. If it’s truly open, lets commit to it.

Anything in between makes people hesitate to believe and that’s how communities start to fracture.

what do you think? what makes you trust an open-source project long term, and what are the red flags that make you cautious?

this is the first meme I have ever made (yes I am that old) - so be gentle :)

what does being modern mean to you?

what does modern mean to you?