GitHub - VoidenHQ/voiden: Define, test, and document APIs like a developer, not a SaaS user. No accounts. No lock-in. No telemetry. Just Markdown, Git, hotkeys, and your damn specs.
github.com
Define, test, and document APIs like a developer, not a SaaS user. No accounts. No lock-in. No telemetry. Just Markdown, Git, hotkeys, and your damn specs. - VoidenHQ/voiden

Voiden is an offline-first, git-native API tool built on Markdown - and it very intentionally didn’t start as “let’s build a better Postman”.

Over time, API tooling became heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you’re offline. Testing a localhost API shouldn’t need an internet connection.

So we asked a simple question: What if an API tool respected how developers already work?

That led to a few core ideas:

  • Offline-first, no accounts, no telemetry

  • Git as the source of truth

  • Specs, tests, and docs living together in Markdown

We opensourced Voiden because extensibility without openness just shifts the bottleneck.

If workflows should be transparent, the tool should be too.

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

Download here : https://voiden.md/download

  • dafalcon@lemmy.worldEnglish
    9·
    16 hours ago

    The one of the most important features - I see thats not mentioned by the author of the post here - even though it should be super highlighted - Voiden is the first client where the entire api request is deconstructed into reusable blocks.

    Headers, Query Params, Path Params, Body (JSON, Form params etc)…

    and reuse them in different apis to have ALL common elements done in one file and then change them once and it will all get updated in all the other docs (just like in code - when we add a extra logic to an imported method). thats super super convenient and saves so much time compared to all the other tools out there - where you mainly duplicate stuff or just use environment variables to substitute.

    OH and the pre and post request scripts - with the support for different languages like JS, python etc … its amazing… first API client i use where you can write pre and post api requests in a different language than JS (as a non JS developer this is huge)!

  • chrash0@lemmy.worldEnglish
    18·
    1 day ago

    i’ve been looking for a silver bullet in this space. hurl[1] seems promising as well. i feel like Bruno has always been jank, and going 1.0 didn’t help. at work i’ve stuck to vibe coding my API test code with a stack of TOML configs, that way i get to reuse/test my client code as well.

    what i want is something version controllable with lightweight dependencies that i can automate easily. i’m afraid that discounts this project. not going to ask my team to download Yet Another Electron API client UI. i’m hesitant to introduce hurl, which can at least be scripted.

    1: https://hurl.dev/

    • nikolasdimi@lemmy.worldEnglish
      7·
      1 day ago

      hey, nikolas here (part of the team of Voiden)- I am keen to understand more if you dont mind. Which of the preferences you mentioned discounts this project? the version control and lightweight?

      I guess you are you referring to the tool being on Electron (Since the version control is handled through the native git integration)?

      We used electron cause allows to deliver the same experience across Windows, macOS, and Linux, and makes it easier to iterate quickly in these early stages.

      a few points:

      • Some apps do feel heavy because of how they are structured : monolithic cores, always-on cloud layers, or unnecessary background services. Voiden is (intentionally) built with a lightweight core: offline-first, Git-native, and without extra baggage.

      • Voiden uses a plugin architecture. This means that we have a small core and all the extra functionality is optional (users can enable or disable plugins) so the base app stays small while the ecosystem can grow. Community contributions or advanced features don’t inflate the core, they live in plugins that users opt into.

      At the same time, there is no special tie to Electron :) We evaluated other options as well but we felt they didn’t offer the same support for all the features we wanted to deliver.

      But we intentionally designed the plugin SDK to be framework-agnostic, leaving the door open to switch the core to a different framework in the future if it makes sense.The goal is a tool that stays lean, extensible, and adaptable as it evolves.

      apologies for the long answer - hope it makes sense?

      • aksdb@lemmy.worldEnglish
        2·
        7 hours ago

        One thing your answer dodges is the automation part. Do you plan on offering a cli to run individual workflows/scenarios? The UI is awesome for building and maintaining the workflows, but if I want to use them for automated testing for example I need to be able to run them headless.

      • chrash0@lemmy.worldEnglish
        2·
        20 hours ago

        first, i’m biased. i’m a home row kind of guy. i live in the terminal.

        Which of the preferences you mentioned discounts this project?

        i’ll be direct: light weight dependencies. i understand why you’d use Electron to build a UI, but does an API tester need a UI as a first class feature? i think something like hurl shows it’s not necessary. i get that maybe it’s an accessibility problem (juniors and Java devs being afraid of the command line etc), but UIs are not composable. i could run hurl (or curl for that matter) via bash or nushell or Elisp or Rust or Powershell or JavaScript or GitHub Actions or as a k8s postDeploy… and, not to draw the ire of Lemmy armchair zealots, they’re not easily usable by agents. an 8B model on my Macbook could figure out hurl, no MCP or crazy preprompting required.

        plus: user adoption. this is the self hosted community, so maybe not everyone here has the same concern, but i can’t just commit a bunch of exotic files to my shared repositories. Bruno was a tough adoption, even though it seems obvious to version control this stuff and it was the only real option at the time. now i’m tired of Bruno cuz it goes out of date cuz it’s not easily scriptable with our internal auth services because it runs everything in its bespoke UI. if they haven’t made a button for it, you can’t do it. that’s the problem with UI dev tools.

        no shade, i understand some people would be totally lost if their IDE didn’t have a big green run button.

        • nikolasdimi@lemmy.worldEnglish
          5·
          16 hours ago

          I actually agree with most of your premise.

          Voiden is not coming from “people are too scared of the terminal, let’s save them with buttons.” It comes from almost the opposite direction. A lot of us are terminal people too. The problem is not that curl, hurl, scripts, OpenAPI, or plain code are bad. The problem is that API work tends to get fragmented across too many places once it becomes real.

          You have raw requests in one place, auth logic in another, docs somewhere else, examples in Slack, test cases somewhere else again, and then different teams consuming different versions of what is supposedly the same API. That’s the mess we care about.

          So the goal with Voiden is not to replace power-user workflows but to give them a better structure, while also making that same source of truth usable by the rest of the team, including people who are not living in the terminal all day, or simply have different preferences.

          That is also why composability matters so much to us. Reusable headers, auth, query params, payload fragments, shared blocks, documentation alongside execution , not because curl cannot do requests, but mainly because nobody wants to maintain the same slightly different request 100 times across scripts, docs, and collections.

          And on the “UI tools become dead ends” point: yes, that is the trap we are trying to avoid. We do not want a bespoke black-box UI where if there is no button, you are stuck. The idea is to have one source of truth that can still work for power users, can be versioned in Git, can be shared, can be documented properly, and can evolve into automation/CLI/agent workflows as well.

          So from my side it is not “UI versus terminal.” That debate is honestly a bit too small. What if we reframe this to: “Can we have one composable, reviewable, reusable representation of API work that serves both the terminal-native people and the wider team without duplicating everything across five tools?”

          That is basically the whole bet.

          So yeah, I get the skepticism. I have it too. The world does not need another glossy “API client” that turns into a toy the moment you step outside the happy path.

          The point of Voiden is precisely to avoid that fate. I am sure you will see how radically different Voiden’s take is, if you just give it a spin for a few mins. In a world full of postman clones - we want Voiden to really stand out with a different approach to api tooling. :)

  • melfie@lemy.lolEnglish
    4·
    1 day ago

    Postman never appealed me for these exact reasons, and I usually just use curl, but this looks like a great option.

    • dafalcon@lemmy.worldEnglish
      3·
      16 hours ago

      It’s 2026, and we’re still essentially filling in the same request forms from almost two decades ago. Headers table. Params table. Body tab. Raw/JSON toggle. Postman’s surrounding ecosystem grew. The pricing model evolved. The cloud story expanded. But the core interaction model barely changed.

      For a company that once redefined API tooling, I feel they dropped the ball in innovating the hell out when they had the chance. Now they are burdened by their own success - cant move and cant adapt. Only squeeze people for more.

      And maybe the bigger impact, sadly of Postman, is what happened to the ecosystem. Because Postman defined the category so strongly, most competitors copied it. For years, innovation in API tooling meant “Postman, but open-source” or “Postman, but git-based.” The dominant UX pattern became the ceiling. Everyone optimized to replace it - few tried to rethink it.

      And I think thats where I see tools like Voiden as a breath of fresh air - a modern take, composable blocks, programmable interfaces. I love it. I dont want to be clicking 100 buttons to figure out whats in my api “tab”. :D

    • nikolasdimi@lemmy.worldEnglish
      4·
      1 day ago

      yap, I think the plain text all the way from design, tests and docs is powerful. Looking forward to any thoughts you might have when you try.

      • dafalcon@lemmy.worldEnglish
        2·
        16 hours ago

        quite cool - i think voiden is similar in premise to verb - but it is more easier to manage for non emacs folks. But i’ll check it out - emcas will bring back the ptsd from my phd days of writing my thesis on it :D

        • banshee@lemmy.worldEnglish
          1·
          12 hours ago

          I really think tools like voiden, hurl, and verb make sense. They make it easier to troubleshoot a system later or to share requests with other developers without leaving the repo. The only real challenge becomes handling authentication scenarios without putting secrets in plain text.

          Speaking of writing a thesis, I imagine that leaves plenty of room for PTSD! I personally like the direnv support for emacs much more than other environments, and I’ve become a big fan of ripgrep and fuzzy finding.