Voiden vs The Field

An API client where your requests, docs and reusable blocks live in plain Markdown files.

Switching? Import fromPostman Insomnia Bruno OpenAPI

Voiden vs The Rest

Feature	Postman	Insomnia	Bruno	Voiden
Open Source
Git-Native (No Export)		Git Sync. Free up to 3 users
Plain Text Format
Executable Documentation
Reusable Block System	Variables Only	Variables Only	Variables Only
Plugins
Works Offline
No Vendor Lock-in	Partial. Account required	Partial. Account required
Built-in Terminal
Pre and Post Requests	Sandboxed packages. JS only	Limited sandbox. JS only	npm modules. JS only	Real runtimes. JS, Python and Bash
Scripts that run before a request is sent and after its response comes back: sign requests, chain tokens, validate results. Postman JavaScript only, in Postman’s sandbox. You can import public npm and JSR packages with pm.require and share scripts through a team Package Library. Private npm packages need a paid plan. Scripts can’t reach your filesystem or local tools. Postman: import packages Insomnia JavaScript only, in a sandbox with a Postman-compatible API, so most Postman scripts copy over. require() only loads a fixed set of built-in modules. You can’t import npm packages. Insomnia: scripts Bruno JavaScript only. By default scripts run in a safe sandbox with a set of built-in libraries. Switch a collection to Developer Mode and scripts can require any npm module from a package.json in the collection. Bruno: external libraries Voiden JavaScript, Python and shell (bash). Each script runs in a real Node.js, Python or bash process on your machine, so it can import the packages you already have installed. All three share the same voiden object: edit the request, read the response, set and get variables, assert, or cancel the request. Scripts live in the .void file, get reviewed in pull requests, and run the same way in voiden-runner on CI. Read about scripting in Voiden
Free Git UI	Free plan. Single user	Free up to 3 users	Commit & pull only. Push paid
Multiple Requests per File
Collection Runs (Stitch Runner)
No Subscription Required	Freemium	Freemium	Freemium
MCP Client (Built-in)
Connect to any MCP server and call its tools, prompts and resources, like testing an API. Postman Built-in MCP requests. You can connect to a server and call its tools from the app, but they live in Postman workspaces, not in files in your repo. Insomnia Insomnia 12 added a native MCP client. You can connect to servers, invoke tools, prompts and resources, and inspect protocol and auth messages. Bruno No native MCP client. You can build the JSON-RPC calls (initialize, then tools/call) by hand as ordinary HTTP requests. Voiden The MCP client block lives in a .void file next to your requests and docs. Paste a server config and Voiden turns it into a block you can run, save and commit to Git. Read about the MCP client block
MCP Server for Your Coding Agent	Separate server. Cloud API key		Separate package	One click in-app. Local, per project
Let Claude Code, Codex or Cursor list and run the requests in your project. Postman The official Postman MCP server is a separate install that you add to your agent’s config. It works with collections in Postman’s cloud, so it needs a Postman API key. @postman/postman-mcp-server Insomnia No official MCP server for coding agents. Bruno The official bruno-mcp package is installed and configured separately. It exposes the requests, folders and environments in your local collections as tools. usebruno/bruno-mcp Voiden Click Initialize MCP in the status bar, or run voiden agent. It writes the config for Claude Code and Codex for that project only. It runs locally, needs no account or API key, and exposes six fixed tools: list files, list requests, run a request, write the result back, list environments and switch environment. Read about Initialize MCP
Publish Requests as MCP Tools	Via API network		Third-party only. via bruno-api-mcp	Per-request opt-in. Test-gated
Turn specific requests into MCP tools that any MCP-capable agent or client can call. Postman Postman’s MCP Generator builds MCP server code from requests you pick on the Public API Network. You then host and run that generated server yourself. Insomnia No way to publish requests as MCP tools. Bruno Only through the community package bruno-api-mcp, which converts every request in a collection into an MCP tool. djkz/bruno-api-mcp Voiden Add a /tool block to a request you already tested. Nothing is exposed until you do. You choose which values the agent fills in and which (like API keys) stay hidden in your environment. A tool is only served while its verification tests pass. Serve it with npx @voiden/mcp, with optional tunnel, OAuth or API key. Read about the tool block

Bring Your Collections With You

You don't have to start from scratch. Import what you already have and get ready-to-run .void files in minutes.

Migrate from Postman

Export your collection as JSON and import it. Folders, requests, headers, bodies and auth come across as .void files.

Import Postman collections

Migrate from Insomnia

Bring over your Insomnia workspace with the Insomnia importer plugin. Folder structure, params, bodies and auth are converted for you.

Import Insomnia collections

Migrate from Bruno

Point Voiden at your Bruno repository. .bru files and OpenCollection YAML exports are imported, with environments, auth, assertions and simple scripts.

Import Bruno repositories

Start from an OpenAPI spec

Import an OpenAPI or Swagger spec and turn every endpoint into a request you can run, document and test.

Import OpenAPI specs

What Makes It Different

Most API clients can store collections in Git now. Here's what's still different.

Collection Files vs Documents You Write

Others

Postman, Insomnia and Bruno can all save collections as YAML files in your repo. But those files are written by the app, usually one file per request, and you edit them through the app's UI. Postman and Insomnia also need an account for most features.

Result: Git-friendly, but built for the tool to read

Voiden

A .void file is a Markdown document you write yourself. Put several requests, notes and checks in one file, read it on GitHub, and open it without an account.

Result: Your repo is readable by people, not just the app

Inherited Settings vs Composable Blocks

Others

You can set auth (and in Insomnia and Bruno, headers) on a collection or folder, and requests inside it inherit them. But reuse follows the folder tree: a request only inherits from its parents, and parts like bodies can't be shared except through variables.

Result: Reuse is tied to where a request sits

Voiden

Every part of a request is a block. Create an auth block once, import it into any file. Create a headers block, reuse it across folders and projects. Change the block, and every request that imports it updates.

Result: DRY (Don't Repeat Yourself) for API work

A Docs Tab vs Docs Around Your Requests

Others

Each request or collection has a Markdown docs tab, and Postman and Bruno can publish those docs as a site. But the docs sit in a separate tab from the request you run, so explaining a whole flow means jumping between requests.

Result: Docs and requests live side by side, not together

Voiden

Write Markdown around your requests. Explain the endpoint, show examples and describe edge cases in the same file, then run each request right where it's documented. The response shows whether the docs are still true.

Result: One document that explains and runs the flow

Ready to Try a Different Approach?

Bring your Postman, Insomnia or Bruno collections and keep working in plain files.

Download Voiden See how to migrate

Free and open source. No account needed.