Login

u/GuaranteePotential90

▲ 10 r/DeveloperJobs

Open Source Community - Invitation for developers of all levels with some experience in API work

Hey there,

Saw a similar post and I thought it was a good idea.

With some colleagues from a previous project we are working on a project called Voiden, its a new kind of API tool. The team is looking for contributors. Every Friday there is also an office hours session to discuss features, roadmap and help those starting out with OSS.

If this is interesting, pls join the discord community: https://discord.com/invite/XSYCf7JF4F
project repo: https://github.com/VoidenHQ/voiden

Thanks!

reddit.com
u/GuaranteePotential90 — 8 hours ago
▲ 2 r/devworld

Looking for postman or insomnia power users to try this API dev tool (offline, no signup)

Bit of context first: 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.

Our team lives in Git, our communication is happening on slack, our docs written and maintained on confluence and after some time they always drift away from the actual requests inside Postman.

So we built and open sourced Voiden a few months ago: an API tool where all that: specs, tests, context and docs are always together in the same executable plain text file (markdown). We also made this Git native so that every change is versioned and tracked just like code.

The last change we have made is to add a Runner so that one can run the files directly from the terminal and CI/CD pipelines.

here is the tool: https://voiden.md/download

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

So my main request is for Postman or Insomnia or other legacy API tool power users. Does this resonate and fit your workflows? Anything that you would consider or suggest adding?

https://preview.redd.it/tqcvszb5hg2h1.png?width=1666&format=png&auto=webp&s=3df8b8838c68c97243949d999c8d8bbf0578a31d

reddit.com
u/GuaranteePotential90 — 10 hours ago
▲ 8 r/SaasDevelopers

An API Client for People Who Like Obsidian and curl

Bit of context first: 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. 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. 

https://preview.redd.it/9613dvtco32h1.png?width=2954&format=png&auto=webp&s=ff0a505f252717da18d2dad7f0232045166ba6d6

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 github 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.

Getting started: You can import your Postman collections and openAPI specs: https://docs.voiden.md/docs/getting-started-section/getting-started/postman-import/

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

Download: https://voiden.md/download

reddit.com
u/GuaranteePotential90 — 2 days ago
▲ 6 r/indiehackersindia

Wanted something closer to how folks code than a GUI API client, so we built Voiden

Bit of context first: I am a member of a 30 people team and most API clients I had used felt like they were built for a different job than what I actually do. Our team lives in Git, and our docs always drift away from the actual requests inside Postman. The fear I kept hearing from other devs when I floated the idea was "I don't need another bloated API tool", and honestly I agreed. I wasn't trying to add a tool, I was trying to delete one.

So the bet was: what if the API client was just Markdown files in your repo, the same way tests are. No workspace, no account, no sync daemon. Requests, auth, params and body are composable API blocks you can reuse across files like functions, and the whole thing runs offline. That's what I ended up shipping as Voiden (https://voiden.md/), an open source API client that stores everything in plain .void files you can diff and review in a PR.

What it does today:

  • REST, GraphQL, gRPC, WebSockets (as plugins, install only what you need)
  • Postman and OpenAPI import so you don't redo years of work
  • 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
  • Free, open source

Disclosure: it's my project, so obviously biased. I am mostly looking for honest feedback from folks here who have tried to move their team off Postman, especially around the migration friction and whether the "everything is a Markdown file" pitch actually clicks or sounds like more work.

What would make you not switch?

download: https://voiden.md/download

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

u/GuaranteePotential90 — 2 days ago
▲ 2 r/founder

Built an offline API client that brings API requests, tests and docs together, in Git instead of a separate workspace

Spent about two years watching our own API work drift across four tools. Requests in Postman/Insomnia, docs in Notion, decisions buried in Slack threads, and a Git repo that knew nothing about any of that. Every time someone asked "is this endpoint still right?" we had to check three places and usually one of them was wrong.

So we stopped trying to glue them together and built the thing we wanted: an API client where requests, tests and docs live in the same plain executable markdown files inside the repo, composed from reusable blocks (endpoint, auth, params, body), runnable from the editor or CLI, offline, no account, no cloud sync.

Open source: https://github.com/VoidenHQ/voiden

https://preview.redd.it/fmdpwxk8rv1h1.png?width=1658&format=png&auto=webp&s=61521adc0753eb98aa1519f0854cae2bd21ac217

The bet is that if API work is just text in Git, it stops drifting because PR review catches it the same way code review does. Our first users, already crossed 11k installs, are mostly backend folks who were already fighting Postman's collection format in their repos.

The part I am still figuring out is positioning. Half the devs I talk to immediately get it because they have felt the drift. The other half say "curl and a README work fine" and they are not entirely wrong for their stage.

How have you handled selling a workflow tool to people who think their current workflow is fine? Do you lean into the pain stories or just wait for them to feel it themselves?

reddit.com
u/GuaranteePotential90 — 3 days ago
▲ 4 r/typescript

Open-sourced a TypeScript API IDE using Markdown instead of Postman-style collections

hey to everyone,

This open-source tool recently reached 1K GitHub stars and around 12K installs. Sharing here in case its useful to other TypeScript devs. It’s fully free and open source.

Its an offline API devtool and what is special about it is that requests live as executable markdown and are versioned in Git. 

Just to give a bit of a background, the inspiration is Obsidian-style files and curl. As opposed to to other tools I have used, everything in Voiden can be composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across executable markdown files. 

Since open sourcing, got a lot of feedback, ideas and contributions and most of the stuff added comes from this feedback: chaining requests, scripting, and structuring everything into reusable .void files. So mainly workflow stuff. The next big item we are looking to add is the CLI runner (maybe its one one of the things I hear more).

A bit of context for the workflows:

Scripting: I want to highlight this one cause in other API tools scripts live in a constrained JS sandbox. In Voiden nope. Since it runs locally, we were able to flip that and allow scripts to run in real runtimes: JS, Python, shell (and will add more).

Multiple requests per file (mini workflows): Putting multiple requests in a single .void file was an idea from a user. You can group full flows together (create-pay-confirm), or full CRUD cycles. The file becomes an executable workflow where docs and tests live together naturally, and you can run one request or the entire sequence end-to-end. 

Stitch (workflows across files): This is our take on the collection runner. Workflows (“Stitch”) are built from .void files that you can combine across scenarios. You define small flows (auth, setup, CRUD, etc.) and stitch them together into larger workflows (without duplications).

Agents: Added “skills” so Claude or Codex agents can work directly with .void files using your own environment and subscriptions. Yeah, one of the perks of everything being file-based and Markdown-first. 

+ We also built an SDK for community plugins and spent time improving performance, reliability, and keyboard-first DX (Electron-based, so we have been careful there).

For those that work with Postman or Swagger I wanted to make it easy to import and try this: https://docs.voiden.md/docs/getting-started-section/getting-started/postman-import/

Looking for feedback and ideas from anyone interested.

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

Download: https://voiden.md/download

https://i.redd.it/om296279r21h1.gif

reddit.com
u/GuaranteePotential90 — 7 days ago
▲ 5 r/buildinpublic

Built internally, open sourced, now at 1K stars on github

If you flip a coin 9 times, the chance of getting heads (or tails) every time is about 0.2%.
That is roughly the same rarity as a GitHub repo crossing 1K stars ⭐ (saw it on star history dot com).

A few months ago I open sourced Voiden, a local-first API client that was originally meant to replace how we work internally with APIs and add to our existing toolset alongside Postman.

But then one day a dev in the team said, "I haven’t logged in to Postman for a week, you know...". That made me believe it might be worth sharing with more folks.

We built this thing in our spare time to scratch our own itch, and suddenly it felt like maybe other devs had the same problem. So we open sourced it, and the question I had was: "Are we the only ones who think API tools feel unnecessarily painful?"

The answer came in the form of a nice milestone: 12k installs and 1K+ GitHub stars.

The way it grew was pretty simple: put it out early, ship fast, listen to feedback, repeat. The main focus has been feedback.Almost everything added since open sourcing came directly from users proposing ideas and contributing.

So in the end, the community is helping improve our internal tool, and at the same time everyone gets something new to improve their own workflows.

Pardon the excitement, but this is my first experience with open source, and this idea of getting so much from people you don’t know (and who simply like your vision) is beyond exciting.

Still early, but this one feels good so wanted to share.

If you work with APIs day to day, or your team does, you might find it interesting. People sometimes describe it as “like Obsidian for API work”, which is probably the simplest way to explain it.

repo: https://github.com/VoidenHQ/voiden
download: https://voiden.md/download

u/GuaranteePotential90 — 8 days ago
▲ 5 r/VibeCodeDevs+1 crossposts

Hey there,

Built and Open Sourced Voiden, an offline API tool that we originally built to replace Postman internally in our team.

This is not a vibe-coded tool (although yeah we do use AI), but we recently added something that might be useful if you are building things with Claude or Codex.

https://reddit.com/link/1t66l0j/video/yc8ab78ezozg1/player

When you build and vibe code apps or tools, you often need to connect to other services, for example:

  • logging users in
  • fetching data from a database or a third-party service
  • sending updates somewhere (like saving a profile or posting content)
  • many other cases

These connections usually happen through APIs, so you need to test that their endpoints actually work.

For example:

  • does login actually succeed and return what you expect?
  • does a full flow like login → fetch data → update something → delete it actually work end-to-end?
  • can you rerun the same sequence without manually clicking around every time?

This is the gap Voiden tries to close with AI skills, giving your agents a small “understanding layer” for testing APIs.

Once enabled, Claude or Codex can understand how API workflows are built, so they can work with full flows instead of isolated requests.

In practice, this means:

  • you can build full API flows, not just single calls
  • AI can modify or improve existing test setups instead of rebuilding them
  • your API tests stay structured so you can rerun them

So instead of “generate a request and hope it works”, it becomes “build a flow you can actually rerun and trust”.

Especially helpful if you are new to APIs, because it makes them feel like simple step-by-step workflows instead of low-level technical calls.

It’s free, offline, and has no telemetry.

welcome to try and let me know your thoughts!

Repo: https://github.com/VoidenHQ/voiden
Download: https://voiden.md/download

reddit.com
u/GuaranteePotential90 — 14 days ago
▲ 1 r/founder

When does it actually make sense to open source something and when is it just a distraction?

For a long time I thought open source meant free software, usually maintained by the community, and something you do when you are not trying to build a business around it.

Building and making a tool open source made me sort of unlearn that.

There is no grand hidden twist in the story: We were frustrated with the state of API tooling, built something for ourselves, showed it to users, and realized very quickly that we shared the same pain with other folks as well.

And because our actual business was elsewhere, we had an unusual amount of flexibility. We didn’t need the open source tool to be a revenue source, and this is what changed the equation for us.

So the decision to open source it was quite practical and I am very happy with it.

Here are my two cents around the debate to open source or not:

1. Open source only works when it doesn’t threaten the core business

If your open-source project needs to become the business, you might eventually start making compromises that feel subtle at first, but can compound over time.

2. Timing matters more than intent

I used to think open source was about intent and ideology, that you believe in sharing, opening etc. But timing is also important, perhaps even more.

In our case, we didn’t open source from, day one. We did it after we:

  • used it internally a lot
  • validated real demand from real users
  • knew and were sure we could support it properly

If we had done it earlier, it would have been performative. If we did it too late, it might have become a closed product by inertia.

  1. Open source does not mean “less responsibility”

Again, I often used to associate open source with less ownership but in practice, it’s more like owning in public.

That means:

  • decisions are visible
  • tradeoffs are questioned
  • and you don’t get to silently rewrite history anymore 😄

So perhaps even more responsibility and a different kind of pressure.

4. Distribution is not the same as adoption

Another misconception I had early on: “open source means that it will spread on its own.”

Good luck. You still need clarity of product, positioning, and a reason for people to care.

If anything, it forces you to be more honest about whether people actually want what you built.

5. The important question is not “open source or not” but "what do you want to optimize for?"

  • Control or collaboration?
  • Revenue leverage or ecosystem adoption?
  • Speed of iteration or breadth of feedback?

For us it was easy to decide when we realized our tool will benefit more from being shaped in the open than from being tightly controlled.

And for other founders thinking about it, the only real question I would leave is this:

Are you opening it because it helps the product evolve , or because you are not unsure what else to do with it?

I think this answer changes everything.

Link to our repo: https://github.com/VoidenHQ/voiden

u/GuaranteePotential90 — 15 days ago
▲ 0 r/Markdown

Hey hey,

So I have a kind of a theoretical question. So one of the things I liked about md files is that they can be used for almost everything. Also, while building Voiden (an API IDE) it was mainly Obsidian and other markdown based tools that inspired me. Ok for my case, it was also curl.

Now lets go the main thing: One thing that turned out surprisingly easy is how friendly it became for agents. This was admittedly not intentional from day one since I didnt build it with agents in mind, I was mostly focusing on devs and qa folks. However, it was a nice add on.

Now, I keep seeing some comments and statements that markdown is more for human and json is the agentic language.

Also here: https://www.reddit.com/r/BlackboxAI_/comments/1sun5jq/companies_are_actively_stopping_writing/

What is your take? I find it strange but wanted to get some opinions from experts.

https://preview.redd.it/bquydfqbdhzg1.png?width=876&format=png&auto=webp&s=83d3c545c56c4fd5c58fae8ec099b88371dfbdef

reddit.com
u/GuaranteePotential90 — 15 days ago
▲ 7 r/startups_promotion

Hey there,

A few months ago we open sourced Voiden, an offline API client we originally built to replace Postman internally.

Voiden now has around 11k installs and growing every day. ❤️

Core principles we built it on:

  • free and local-first
  • file-based, all plain executable markdown
  • composable through blocks
  • collaboration in Git, where devs are working already

The main thing is that in Voiden, API requests are not (static) forms. They are built from blocks (endpoint, auth, params, body) that can be used, reused, replaced and version in Git, just like code. And all that in plain executable text.

https://reddit.com/link/1sytwys/video/miw4j5fxm3yg1/player

Our inspiration:

Our inspiration was curl, and how simple it is, and obsidian, because of how powerful it can be.

Who this is for:

Developers, QA, Technical Writers working and collaborating on APIs.

Progress:

Since open sourcing, almost everything that we shipped came from actual users, feedback and contributions that pushed the tool in a few interesting directions. You can check our change-log here: https://voiden.md/changelog

A few highlights:

  • Composable API workflows: Voiden lets you build reusable .void files that can be combined into flows, run multiple requests in sequence, and use real scripting (JS/Python/Shell) before and after requests.
  • Added a “skills” layer so tools like Claude/Codex can operate directly on .void files and request blocks.
  • We added an SDK for community plugins.
  • & more...

Feedback:

This project is now mostly shaped and driven by community ideas and contributions. Welcome to join and help us make this even more awesome.

There is no account setup, its free and totally offline.

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

Discord: https://discord.com/invite/XSYCf7JF4F

Download: https://voiden.md/download

reddit.com
u/GuaranteePotential90 — 22 days ago