Wanted to provide an update around the CLI runner that we shipped a few days ago. This was already on beta for quite some time so now that its on stable, I thought of giving it another go in the community.

For those who are not familiar with the tool and what the h#$@ I am talking about: Voiden is an offline, git-native API tool built on Markdown.

We built it (and then open sourced it) because API tooling sucked (and we work a lot of APIs enough to care to do something about it). I will just name a few issues: cloud dependencies, forced accounts, proprietary formats plus many more.

Long story short, this is Voiden: instead of keeping API requests inside a cloud workspace, Voiden stores them as .void files that can live with your codebase, be versioned in Git, reviewed in PRs, and reused across a team. Plus everything is plain executable markdown. By "everything" I mean really everything: API specs, tests, docs, context...everything.

We have now released the @voiden/runner, which is a headless CLI for running those .void files outside the desktop app.

The runner executes the requests, prints the results, and exits with a standard exit code that CI systems can use.

Things to note:

• runs on Node.js 18+
• works in terminal, CI/CD, Docker, and cron jobs
• supports REST, WebSocket, gRPC, and GraphQL
• supports request chaining through runtime variables
• works with core Voiden plugins like scripting, assertions, faker, advanced auth, + more.

The ultimate goal is to make .void files executable API workflows, not just files used inside the desktop app.

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

Voiden CLI Runner : https://github.com/VoidenHQ/voiden/tree/beta/packages/voiden-runner

Visit Voiden here : https://voiden.md/

P.S this post is mainly around the Runner but every feedback outside that is also welcome, especially coming from any postman or insomnia power users in the room :)

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

A broke NYC punk girl in the early 80s, absolutely determined to become famous… mostly by hanging around people who are also going nowhere.

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.

Fight for Your Life (1977) is an aggressively "trashy" grindhouse movie where a racist psycho and his cartoonishly awful henchmen take a family hostage, only to get schooled in chaotic violence by the family’s grandpa.

Extreme, over-the-top dialogue , a bizarre, offensive black comedy cult film (and less the gritty drama it tries to be.)

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

Note - This post is intended to look for feedback in a tool that solves a problem we have been seeing (around API clients not supporting Python) - and hopefully help Python folks (like it helped us when building it).

So, a bit of a backstory - Something I noticed while we were building our internal tool for API testing: A lot of developer tools assume JavaScript scripting by default. API clients are a good example of this.

scripting = JavaScript

And yes it might not be always a huge problem, but it adds constant friction.

Eventually we realized the real issue was not just JavaScript. The issue was and is that many tools force a single language.

So when we started building our own API client (link below), we decided to approach scripting differently: Pre-request and post-request scripts support multiple languages and runs on real interpreters, not a limited sandbox like most Clients do.

So we built this to support Python and JS from day 1 and now releasing shell script + more coming (perhaps Go would be the next??)

The idea is simple: Your API tool should adapt to your stack, not the other way around.

Some developers think in JS, some in Python, some in Go or Rust.

The tool shouldn’t care.

Q: Would you actually use Python for request automation inside an API client, or do you prefer handling that logic outside the tool?

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

has anyone seen this masterpiece?

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?

has anyone seen a worse haircut than Ator's in this film?

Full movie: https://www.youtube.com/watch?v=6wRznqH9IbA&t=254s

I heard there is a sequel but dont have the courage to watch it.

full movie here: https://www.youtube.com/watch?v=cm2FbJE2wsQ

"If you can meet with Triumph and Disaster / And treat those two impostors just the same"