Went through a competitor's stargazers. Most of them aren't real.

I open sourced an API IDE this year. Same space as Postman, Insomnia and the rest, but at the same time nothing like them: everything is plain text files in your repo, offline, no account etc.

One of the first things I thought and cared about in the early days was of course downloads and installs. And secondarily, it was stars.

And yeah, some of the competitors (that are also open source) have star counts I envied.

And we didnt do bad, we got 1000 stars relatively easily, with the first launches, rollouts. Developers seem to love what we are doing (the fact that we are not trying to clone Postman and make sth unique instead).

Recently I did the grubby founder thing and opened a competitor's stargazers list (one of the big ones). Partly curiosity, partly hoping to find some users or emails to reach out to. Not proud of it but ok, I was just curious to see who are the users.

Except there were almost no people in there.

Accounts a few months old. Zero repos or one fork. No activity. Multiple usernames like 4145243@ere.com. Public emails that were pure gibberish. Pages and pages of this.

How did this happen? : either they bought stars , or bot farms starred them to make the bots themselves look legit. I

In the beginning I was looking up to the stars but it seems they are as about as real as Instagram followers in 2015.

The only thing my outreach scheme found: the audience I was envying might not exist.

p.s. here is the repo of my tool , in case you wanna have a look.

https://github.com/VoidenHQ/voiden (yeah we have 1272 stars right now and they are all actual devs :)

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 :)

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?