Voiden: an offline, Git-native API client built on .void files

One file holds the request, the test and the documentation

Voiden is an offline API client for developers, QA engineers and technical writers, and its central idea is that the artefacts of API work should not be scattered. Requests, tests, notes and docs are kept together in the same executable .void files, in a format the README describes as plain text and structured blocks rather than opaque collections locked inside an application.

The consequence is a different collaboration model. The README lists collaboration with Git branches and pull requests instead of proprietary team workspaces, and staying local-first with no signup and no required cloud sync. It is also explicit about the commercial position: no accounts, no required cloud sync, no telemetry, no VC funding and no cloud lock-in. The application is built with Electron, TypeScript and JavaScript, and it does not require an account to use it.

The argument for that design is about where the source of truth lives. In a client that stores a collection in a private format, the collection is a binary asset that nobody can review, and the only way to share it is to export it. In Voiden the collection is a set of text files in a repository, so a reviewer sees what changed in a request the same way they see a change in application code, and a new engineer can clone the repository and run the same calls without asking anyone for a licence key or an invite.

The stated audience is broader than developers alone, which is the point of the format. A QA engineer and a technical writer working in the same .void file as the developer who wrote the endpoint is a workflow that a cloud workspace usually handles with separate artefacts and a permissions model.

Requests decompose into reusable API blocks

The composability model is the part that decides whether the format scales past a handful of calls. The README states that requests can be composed by API building blocks, namely endpoint, auth, params and body, and that you can decompose requests into blocks and reuse the same blocks across files, like functions.

That reuse is the interesting part, because it is the reason a .void file can be a source of truth rather than a log of past requests. A request that appears in a smoke test, in a debug session and in the API documentation is the same block, referenced three times. Change the base URL or the auth block in one place and all three follow, and the change shows up in the Git diff as a change to one block rather than as three divergent copies of a request.

The same design explains the versioning language in the project description, which speaks of reusing, replacing and versioning everything just like code. A .void file is therefore expected to be branched and merged, and the repository stores these files under version control with a diffable, greppable, merge friendly format.

The trade-off is that this is a more demanding format than a flat list of requests. There is no binary export and no proprietary workspace, so there is also no GUI to assemble a request for someone who does not want to edit text. The README is direct about that trade: work in Markdown and structured blocks instead of opaque collections.

Protocols are plugins and collections can be imported

Protocol support is pluggable rather than hard coded. The README states that Voiden supports REST, GraphQL, gRPC and WebSockets, and that all of them are plugins which you can install or uninstall according to your needs, with community plugins listed on the project's plugin page. The repository layout supports that reading, with an apps directory, a packages directory, a scripts directory with a build-plugins script, a setup script for plugins and a registry sync script in the root package.json.

The other half is getting data in. Voiden supports importing collections from Postman, Insomnia and Swagger or OpenAPI documents. For a team switching tools, that import path is the first thing to test, because a collection that imports lossily is a collection your team will rebuild by hand inside a week.

The plugin model also shapes the runner. The Voiden Runner, a headless CLI for running .void files outside the desktop app, supports REST, WebSocket, gRPC and GraphQL, and works with core Voiden plugins such as scripting, assertions, faker and advanced auth. The same plugin set therefore works in the editor and in a pipeline, which is what makes the desktop app and the CI runner one system rather than two.

The project positions itself in this space directly. Its topic tags list bruno-alternative, insomnia-alternative and postman-alternative, so the comparison you will be asked about is with the incumbents. The difference in approach is the storage layer: those tools keep collections in a workspace, in a project file or in a cloud account, and Voiden keeps them as text files in your repository with no account involved.

Scripting hooks and the Stitch runner for batch execution

Two features cover the part of API work that a plain request list cannot. The first is scripting, which lets you execute JavaScript, Python or Shell scripts before sending requests and after receiving responses. Pre-request scripting is how you compute a token or a timestamp, and post-response scripting is how you extract a value for the next call.

The second is the Stitch runner, for batch execution of multiple .void files sequentially. The README lists what it supports: glob patterns, stop-on-failure, variable isolation, configurable delays and environment selection. Each of those is a decision about how a suite behaves.

Glob patterns are how a suite scales, since you point the runner at a set of files rather than listing them. Stop-on-failure is how a pipeline avoids producing misleading results after the first break, and it is the difference between a check that fails and a check that keeps going and reports a wall of noise. Variable isolation means one file cannot leak state into the next, which matters the moment the suite is run in parallel. Configurable delays throttle the rate at which a staging environment is hit. Environment selection is how the same file runs against local, staging and production, with the environment chosen rather than hard coded.

A test framework built into the client is also the reason the assertions plugin exists, and the faker plugin is the reason seeded, generated data appears in the request bodies. The combination means a test suite is a directory of text files plus a runner invocation, and it lives in the same repository as the service it exercises.

Voiden Runner puts the same files in CI

The Voiden Runner is a headless CLI for running .void files outside the desktop app, directly in the terminal, and it lives in a separate tree in the repository under packages. The README describes it as running on Node.js 18 or later and working in a terminal, in CI/CD, in Docker and in cron jobs, with support for REST, WebSocket, gRPC and GraphQL, and support for request chaining through runtime variables.

The design decision here is that the CI artefact is the same file the developer used interactively, not a re-export. That is what makes the pipeline trustworthy, and it is the opposite of the export-a-collection-to-CI path that forces a conversion step and a second copy of the truth.

Request chaining through runtime variables is the piece that makes multi-step flows possible in a pipeline, since a login call has to produce a value that later calls consume. The plugin support listed for the runner, including scripting, assertions, faker and advanced auth, means the checks that run in CI are the same checks that were run in the editor, not a reduced subset.

The repository also carries RUNNER_MIGRATION_NOTES.md at the top level, which is worth reading before you build a pipeline around the runner, and a set of development scripts in the root package.json for building and watching plugins and for syncing the plugin registry.

MCP support turns the workspace into agent tools

The newest direction in the project is the Model Context Protocol integration, and the README describes it in concrete terms. MCP support lets you connect Claude Code or Codex directly to a project so that they can run your .void requests themselves, or serve your own requests as tools that other agents can call. The MCP documentation lives at docs.voiden.md under the mcp overview page.

The second half of that sentence is the interesting half. If your .void files are the executable description of your API, then exposing a request as a tool means an agent can call your API with the same semantics a human developer would use, including your assertions and your auth blocks, instead of guessing parameter names from a schema.

Two related features sit next to it. Voiden has a programmable interface through slash commands, and it supports Voiden skills for Claude and Codex agents. The README frames this as AI friendly in a fairly specific way: no proprietary workspace, no binary exports, pure text all the way down, diffable like code, greppable, AI-editable and merge friendly.

That framing is the clearest statement of the project's thesis. Most API clients store their value in a private format that only the client can read, and that is exactly the property that makes them awkward for both version control and automation. The MCP integration only works because the underlying format is text, so the two features reinforce each other rather than being a separate add-on.

Installing across macOS, Windows and Linux

The README states the current version as 2.3.2, stable, and points to the download page for installers for macOS, Windows and Linux, with direct downloads for Apple Silicon and Intel macOS, a Windows .exe and Linux .deb, .rpm and .AppImage builds.

Package managers are the better route on a managed machine, and the README lists them per platform. On macOS, Homebrew and Nix are available for the stable channel:

brew install voiden

with a separate beta formula, and on Linux the Flatpak path installs from a flatpak remote:

flatpak remote-add --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
flatpak install flatpark md.voiden.Voiden

Windows has winget and Chocolatey:

winget install Voiden

and Linux also has apt and snap channels, with the repository and keyring added through a documented pair of commands before apt update.

One platform note is worth reading before a Windows rollout. Starting with v2.1.1 the Windows installer is signed via Azure Trusted Signing instead of the previous certificate provider, and the README says you may see a Windows protected your PC SmartScreen dialog during install because the installer is signed and verified and the app is still building download reputation with Microsoft, with instructions to click More info and Run anyway.

That is a real operational detail for a team deploying the client to a fleet of developer machines with SmartScreen policies, and it is the kind of thing that only appears in the documentation because somebody hit it.

Fast releases, a beta channel and Apache-2.0 terms

The project moves quickly. The recent releases are v2.3.3-beta.1 on 2026-10-13, v2.3.2 on 2026-10-09 and v2.3.1 on 2026-10-01, and the last push was on 2026-10-15. Three tagged releases in two weeks, with a beta published alongside the stable line, is a high cadence, and it cuts both ways: fixes and features arrive quickly, and so do changes in behaviour that a team must read the changelog for.

The beta channel is separate in the packaging too. Homebrew has a voiden@beta formula, winget has a Voiden.Voiden-Beta package, and the Linux apt and snap channels have beta variants, so early adopters are not forced onto a tarball.

The licence is Apache-2.0, with LICENSE and NOTICE files at the top of the repository, and the README carries the same licence badge. The build is a Yarn workspace monorepo, with packageManager set to [email protected], an apps directory for the Electron application, a packages directory holding the runner, tests run through vitest, and knip wired up as a separate script for unused code analysis. The repository also carries a Nix flake, a pre-commit style of tooling in scripts, SECURITY.md, CONTRIBUTING.md and a CODE_OF_CONDUCT.md, and a changelog.md at the top level rather than only on the website.

For a team standardising on this client, the practical upgrade question is not whether the project is maintained but which channel you track. Pinning to a stable version and reading the changelog between upgrades is the lower risk path, and the beta channel is there for the people who want the new work first.

Editorial conclusion

Voiden suits a team that keeps its API work in Git and wants requests, assertions and documentation to be reviewed in the same pull request as the code, or a solo developer who wants a client with no account and no cloud. It is the wrong tool for a team that depends on a shared server side workspace with granular permissions, and it is the wrong choice if the .void file format is something you would have to convert to later. Before you adopt it, install the stable release rather than the beta, run one of your existing collections through the import path from Postman, Insomnia or an OpenAPI document, and check that the Voiden Runner covers the protocols and plugins your CI actually needs.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. VoidenHQ/voiden on GitHub