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

  • hikaru755@lemmy.worldEnglish
    0·
    1 month ago

    Gave it a quick shot right now, and gonna be honest - while the premise seems nice, the sample project is very transparently AI slop generated with a prompt that, I can only assume, included an instruction like “for every sentence that doesn’t include a whimsical quip, I’m gonna kill a kitten”. It is absolutely grating to read. I don’t care if you do that in your marketing copy, but keep that shit out of technical documentation, it’s annoying, it’s distracting, and it’s turning me off the entire project. Like wtf is this:

    • nikolasdimi@lemmy.worldEnglish
      0·
      1 month ago

      we are indeed looking at the docs again. To begin with we focused on the tool itself so some of the examples that you see can indeed be worth revisiting and re writing. :) But I hope you can focus and zoom in to the tool itself and see how this can help you with your API workflows.

  • dafalcon@lemmy.worldEnglish
    0·
    2 months 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
    0·
    2 months 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/