We open sourced Voiden a few months ago: an offline API tool where API requests live as executable Markdown and are versioned in Git. We wanted to build something that combines the power and flexibility of Obsidian-style files with the simplicity of curl.

The basic idea of Voiden is that instead of being static forms, API requests are composed by using blocks (endpoint, auth, params, body). Blocks that you can add, reuse, override, and stitch together across files (more like functions than requests).

Most of the feedback, requests and contributions that we have gotten since Open Sourcing, have been around defining workflows, chaining requests, scripting them, and structuring everything in reusable .void files.

These are some of the key highlights that I wanted to share:

– Real scripting, (instead of sandboxes): In most API tools scripting lives in a constrained JS sandbox, an environment that doesn’t take advantage of powerful runtimes that might be available locally for a developer. The biggest limitation here is the assumption that the tool should define the runtime. Voiden runs fully locally, so this allows you to just run your scripts with actual runtimes (JS, Python, shell, with support for others being added).

– Multiple requests per file (mini workflows): Allowing multiple requests in a single .void file turned out to be surprisingly useful. Instead of scattering related requests, you can group them naturally: an order flow (create - pay - confirm), or a full CRUD cycle in one place. The file effectively becomes an executable flow: run one request, or the entire sequence end-to-end. And since Voiden is executable Markdown, docs and tests are in the same .void file that can be organised better, preventing duplication and drift.

– Stitch (composable workflows across files): Instead of a single large collection, 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 duplication. This is just the first version of this capability, we still have a lot to do here.

– Agents :The file-based, local-first model also works well with agents. Since Voiden has a built-in terminal and uses Markdown, we added “skills” so that Claude and Codex agents can work directly with .void files (using your own subscriptions).

We also published an SDK for community plugins, and made improvements to performance, reliability, and DX (keyboard-first), with careful attention to performance given the Electron base

Looking for feedback and suggestions.

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

Download : https://voiden.md/download

Latest Lemmy discussion : https://lemmy.world/post/43922166

We open sourced Voiden a few months ago: an offline API tool where API requests live as executable Markdown and are versioned in Git. We wanted to build something that combines the power and flexibility of Obsidian-style files with the simplicity of curl.

The basic idea of Voiden is that instead of being static forms, API requests are composed by using blocks (endpoint, auth, params, body). Blocks that you can add, reuse, override, and stitch together across files (more like functions than requests).

Most of the feedback, requests and contributions that we have gotten since Open Sourcing, have been around defining workflows, chaining requests, scripting them, and structuring everything in reusable .void files.

These are some of the key highlights that I wanted to share:

-- Real scripting, (instead of sandboxes): In most API tools scripting lives in a constrained JS sandbox, an environment that doesn't take advantage of powerful runtimes that might be available locally for a developer. The biggest limitation here is the assumption that the tool should define the runtime. Voiden runs fully locally, so this allows you to just run your scripts with actual runtimes (JS, Python, shell, with support for others being added).

-- Multiple requests per file (mini workflows): Allowing multiple requests in a single .void file turned out to be surprisingly useful. Instead of scattering related requests, you can group them naturally: an order flow (create - pay - confirm), or a full CRUD cycle in one place. The file effectively becomes an executable flow: run one request, or the entire sequence end-to-end. And since Voiden is executable Markdown, docs and tests are in the same .void file that can be organised better, preventing duplication and drift.

-- Stitch (composable workflows across files): Instead of a single large collection, 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 duplication. This is just the first version of this capability, we still have a lot to do here.

-- Agents :The file-based, local-first model also works well with agents. Since Voiden has a built-in terminal and uses Markdown, we added “skills” so that Claude and Codex agents can work directly with .void files (using your own subscriptions).

We also published an SDK for community plugins, and made improvements to performance, reliability, and DX (keyboard-first), with careful attention to performance given the Electron base

Looking for feedback and suggestions.

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

Download : https://voiden.md/download

Latest Lemmy discussion : https://lemmy.world/post/43922166

I need to scan very large JSONL files efficiently and am considering a parallel grep-style approach over line-delimited text.

Would love to hear how you would design it.

Voiden is an offline-first, git-native API tool built on Markdown Voiden is an API client we have been building that takes a different approach from most existing tools.

It didn’t start with the idea of “building a better Postman”.

A bit of background. Over time, API tooling has become heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you are offline. On top of that, time wasted on fixing API specs that don’t match the code, docs in separate random tools, tests also separate and an overall governance mess. Not to mention collaboration.

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.
• Plain text files: specs, tests, and documentation live together in Markdown
• A programmable interface instead of static forms: requests are composed from reusable blocks (endpoints, headers, auth, params, bodies, etc.) that you can structure the way you want
• Plugin system for extending functionality rather than bloating the core with new features Some of our core plugins include gRPC,GraphQL,WebSockets,etc…

We have just also updated our docs to welcome community plugins, so teams can extend the tool for their own workflows or integrations. https://docs.voiden.md/docs/plugins/build-a-plugin

We opensourced Voiden because extensibility without openness just shifts the bottleneck. If (API) workflows should be transparent, the tools should be too.

Welcome to try out and share feedback- happy to chat with everyone.

Strong opinions are encouraged. :)

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

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

Voiden is an offline-first, git-native API tool built on Markdown Voiden is an API client we have been building that takes a different approach from most existing tools.

It didn’t start with the idea of “building a better Postman”.

A bit of background. Over time, API tooling has become heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you are offline. On top of that, time wasted on fixing API specs that don’t match the code, docs in separate random tools, tests also separate and an overall governance mess. Not to mention collaboration.

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.
• Plain text files: specs, tests, and documentation live together in Markdown
• A programmable interface instead of static forms: requests are composed from reusable blocks (endpoints, headers, auth, params, bodies, etc.) that you can structure the way you want
• Plugin system for extending functionality rather than bloating the core with new features Some of our core plugins include gRPC,GraphQL,WebSockets,etc…

We have just also updated our docs to welcome community plugins, so teams can extend the tool for their own workflows or integrations. https://docs.voiden.md/docs/plugins/build-a-plugin

We opensourced Voiden because extensibility without openness just shifts the bottleneck. If (API) workflows should be transparent, the tools should be too.

Welcome to try out and share feedback- happy to chat with everyone.

Strong opinions are encouraged. :)

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

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