Let me describe a day in the office. Tell me if it sounds familiar.
You need to call the payments API. Just one request. Should take five minutes.
- First stop: Postman. There's a collection for it. It's in a workspace you were never invited to. You ask for access.
- Second stop: Slack. You search "payments curl." You find one from eight months ago. You copy it. The token is expired. The endpoint is still /v1.
- Third stop: the README. It says /v1 too. It also says "see Postman for examples."
- Fourth stop: "ask Maria." Maria set up the auth. Maria is on holiday.
An hour later, it works. You figured out the new endpoint, the right header, and the one weird query param nobody wrote down.
And then you do the most natural thing in the world. You paste your working curl back into Slack.
So the next person can find it in eight months. With an expired token.
Every team has its own version
When I ask developers where their API knowledge lives, I get answers like these:
- "Ask Maria, she set up the auth"
- A pinned Slack thread with three corrections in the replies
- A Postman collection called payments-FINAL-v2
- "It's in Postman. The old workspace, not the new one."
- A Notion page titled "API stuff (WIP)", last edited in 2024
- A curl command in someone's shell history
- A .env file someone sent you in a DM
- A code comment that just says // don't remove this header
- A screenshot of a request inside a Jira comment
- A Loom video from someone who left the company
Most teams have at least five of these. Be honest, how many do you have?
The real problem:
The request itself was never the hard part. The hard part was everything around it:
- Which environment to use
- How auth works
- Why that weird param is there
- What a good response looks like
That knowledge was spread across four places. Each one had a piece. None of them was the full picture.
We lived this exact loop on our own team. It's a big reason we started building Voiden.
What we built
Voiden is a free, open-source API tool (Apache 2.0). It runs locally on your machine, no account needed.
The idea is simple. The request and everything around it live in one file.
A .void file is plain Markdown. One file holds:
- The request
- The auth (as a reusable block)
- Notes on why things are the way they are
- Tests for the response That file lives in your repo, next to the code. When someone changes the endpoint, the change shows up in a PR. Reviewed like any other code.
Same day, with Voiden: you open the repo, find payments/create-charge.void, read the note about the weird param, and hit run. Done before your coffee gets cold.
It doesn't solve everything. Someone still has to write the note. But once it's written, it stays next to the request instead of sinking in a Slack channel.
Try it on one request
Here's a small experiment. Take one curl you keep copy-pasting from Slack. Put it in a .void file. Add one line explaining why it looks the way it does. Commit it.
That's it. See if your future self thanks you.
You can import your Postman collections or OpenAPI specs too, if you want to go further.
Now I'm curious:
Where does API knowledge live on your team today?
What's the strangest place you've found a critical piece of it?
Has anyone found a setup that actually stays in sync?
I'll reply to every comment.
Download: https://voiden.md/download Repo (it's all open source, stars and issues welcome): https://github.com/VoidenHQ/voiden
Top comments (2)
The “ask Maria” part is painfully real 😂
API knowledge usually isn’t missing, it’s just scattered across Slack, Postman, READMEs, and someone’s memory. The real win is making the context travel with the request instead of making every developer rediscover it.
Every team has a Maria. That's pretty much why we built Voiden: the request, the notes and the tests sit in one file in the repo, so the context ships with it.