GitHub - VoidenHQ/voiden: Design, Test, Document APIs, in plain Markdown. Compose APIs with blocks. Reuse, Replace & Version everything just like code. Truly Git Native. No Lock-in.
github.com
Design, Test, Document APIs, in plain Markdown. Compose APIs with blocks. Reuse, Replace & Version everything just like code. Truly Git Native. No Lock-in. - VoidenHQ/voiden

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.

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

Download: https://voiden.md/download

  • atzanteol@sh.itjust.worksEnglish
    7·
    15 hours ago

    Voiden files combine frontmatter, Markdown, and structured void request blocks so the request and the documentation live together.

    This is… An interesting format. Why not just move the front matter field and markdown into the “structured” bit and just have a single thing to parse? Or at least combine the frontmatter and structured bit since they’re both yaml anyway?

    • dhruv3006@lemmy.worldOP
      2·
      13 hours ago

      Interesting point. Are you thinking about this from the parser/tooling side, or from the person writing and reviewing the file?

      We intentionally started from Markdown because we wanted .void files to stay standards-compliant and not reinvent a new document format. Markdown already gives us a familiar, portable way to write docs, notes, examples, and explanations around the request.

      Frontmatter handles the document-level metadata, Markdown stays the human-readable documentation layer, and the structured Voiden blocks handle the executable API parts.

      We could put everything into one YAML object, but then the file becomes more like a config file than a Markdown document. The tradeoff we’re making is: keep the file readable in GitHub, PRs, and plain text editors while it still gives Voiden enough structure to execute requests reliably.

      • atzanteol@sh.itjust.worksEnglish
        4·
        13 hours ago

        From both a tooling and user POV.

        We intentionally started from Markdown because we wanted .void files to stay standards-compliant and not reinvent a new document format.

        Unless I’m missing something you kinda have though? You’ve got a frontmatter bit followed by a MD document with a “footer” that has configuration in it?

        We could put everything into one YAML object, but then the file becomes more like a config file than a Markdown document.

        It seems like a config file to me. But reading through your documentation about blocks it seems like you’re aiming to be something like Jupyter for REST? It’s very confusing.