About Voiden.md

We were working on a project that involved multiple APIs. The usual setup: Postman for testing, Confluence for docs, Slack for sharing context, README for examples. Every time something changed, we'd update one place and forget to update the others.

Then came the moment that sparked Voiden.

We asked ourselves: What if API requests, docs, and reusable auth strategies could live in a single file? In Git. Executable. Reviewable in a PR. Just like code.

Not a workspace in the cloud. Not JSON exports that break between versions. Just plain text files—.void files—that you commit to your repo.

Imagine opening a file in a PR and seeing: "Added OAuth block, updated base URL, fixed the login endpoint." All in one diff. That's what we wanted. That's what we built.

The way we treat API knowledge is broken. We scatter it across Postman collections, Notion docs, Slack threads, and README files. None of it is versioned with the code that actually uses those APIs.

Voiden changes that. It treats API work the way we treat code: modular, reusable, and version-controlled.

You don't copy-paste auth headers into 20 requests. You create an auth block once and reference it everywhere. You don't maintain separate docs—your .void files are the docs. And when you change something, you commit it to Git like any other code change.

No vendor lock-in. No cloud dependency. No proprietary formats. Just plain text files that you control, that work offline, and that live alongside your code where they belong.

This isn't about replacing OpenAPI or other standards. It's about having a file-centric workflow instead of a workspace-centric one. Your API work should live in your repo, not in someone else's cloud.