Why I Moved My API Workflow to a Markdown File (and Never Looked Back)

Davinder Ghatore — Wed, 12 Aug 2026 10:22:57 +0000

Every API tool eventually turns into the same mess.

Your spec lives in one place. Your tests live in another. Your docs live somewhere else, usually outdated by the time anyone reads them. Multiply that across a team, and you get five tools that don't talk to each other and a codebase full of "wait, is this endpoint still doing that?"

That's the exact problem that got me looking at Voiden.

The Core Idea

Voiden is an offline-first, Git-native API workspace. Instead of a dashboard holding your requests hostage in the cloud, everything, your spec, your tests, your docs, lives in one plain Markdown file. That file sits in your repo, right next to the code it describes.

No account to create. No telemetry. No "is the cloud down again" moment in the middle of a sprint.

What Actually Changes Day to Day

A few things stood out once I started using it for real work:

API requests are Markdown blocks

You write a request once, as a composable block, and reuse it across your whole collection instead of duplicating it five times with slightly different headers.

Git-native by default

Because everything is a plain file, an API change and its documentation update land in the same commit, and get reviewed in the same PR. No more "the docs are stale" because the docs are code now.

Multi-protocol support

REST, GraphQL, gRPC, and WebSockets are all supported, with plugins you can add or strip depending on what your project actually needs.

Migration isn't painful

You can import directly from Postman, Insomnia, or an OpenAPI spec. Switching over doesn't mean rebuilding your whole collection from scratch.

Why This Matters More Than It Sounds

The pitch isn't "more features than Postman." It's a different premise entirely: API work should feel like writing code, versioned, diffable, reviewable, not like filling out a form inside someone else's dashboard.

If your team has ever shipped an API change without updating the docs (be honest, we all have), that's the specific failure mode this setup is built to remove. When the doc update is part of the same diff as the code change, skipping it becomes a visible gap in the PR, not a silent debt that piles up.

Worth Trying If
You're tired of context-switching between your API client, your docs tool, and your test runner
You want your API work reviewed the same way you review code
You'd rather keep your data local than trust another SaaS dashboard with it
Your team has ever shipped an endpoint change without updating the docs (be honest)
Try It

You can check it out at voiden.md. Happy to answer questions in the comments if you're curious how it compares to what you're using now.

What's the one thing your current API client still makes annoying, that you've just learned to live with?

DEV Community: Davinder Ghatore

Why I Moved My API Workflow to a Markdown File (and Never Looked Back)