
Aldin
Streamline API Testing with Reusable Building Blocks
Repetition, a time-churning enemy of developers. Remember the time when copy-pasting code was a universal problem in software engineering? Then abstractions came and solved it (functions, libraries, frameworks, etc).
API tooling, however, still grapples with a similar problem: redefining the same authentication tokens, headers, or parameters for every endpoint test. This manual repetition wastes time and invites errors. Copying and pasting all across the collections is somehow considered a way to get things done faster?! Tabs keep the truth across the tools, along with half a dozen other tooling “necessary” to wrap it all up.
Well, Voiden has now removed the duplication from API tooling, applying the DRY (Don’t Repeat Yourself) principle, streamlining workflows, and giving developers control over their API testing process.
From Code to APIs: The Repetition Problem
In the (relatively) early days of software engineering, developers routinely copied and pasted code for common tasks like string manipulation, file handling, sorting algorithms - you name it. A single change that introduces a change in logic meant updating every instance manually. A paradigm change helped build reusable structures, sharing them across the project (or across different projects, even).
In today’s API tooling, testing an API means creating collections where each request often requires redefining the same authentication tokens, headers, or query parameters.
Need to test 50 endpoints?
You’re either manually setting up OAuth2 tokens or rate-limit headers for each one, or copying and pasting across requests. Collections and environments do help, but they still require manual duplication across workspaces or teams.
Voiden.md solves this by bringing software engineering’s modular philosophy to API testing. Its reusable API blocks let you define common elements such as headers, query parameters, etc., and reuse them across your projects, just like you would do in the codebase. Voiden centralizes your workflow in a single, offline, Git-tracked workspace, giving you control and eliminating the repetitive chaos.
How Voiden’s Reusable Blocks Work
Voiden lets you define common repetitive API elements, like authentication tokens or query parameters, in its .void files, and you can import these blocks into other .void files. These files are simple Markdown files, simplifying documentation of the APIs, just adjusted for Voiden execution.
This approach eliminates the repetitive setup needed (at the moment of writing this blog post) in every alternative API tool out there.
Let’s say you’re testing the DummyJSON API’s endpoints (e.g., a https://dummyjson.com/docs/posts), which enables filtering results by using query parameters.
Here’s how to create a reusable block in Voiden:
Hit the Ctrl/Cmd+Enter to create a new project file
- You can name it query.void and save it with Ctrl/Cmd + S
Add a markdown title to describe the file
- Type ## for H2 styling and add Reusable Query Params Block, for example
Type /query and hit Enter
That will create an HTTP query params key-value table
Now populate the table with limit and skip fields along with their values
Optionally, document the fields from the query params table
You should see something like this:

Now you’re ready to use this without having to type it all over again across the project by simply importing it.
Let’s say we already created a flow for triggering the /posts endpoint, but we want to add the query parameters on top of it. (If not, you can learn here how to do that)
You should already see something like this:

To import query params block type @, select Blocks, select the name of the block file (in this case, query.void), and finally select the block you want to import from that file. In this case, the query-table .

That’s it. You can repeat the same for any endpoint that uses these query params without having to define them ever again. Just import and run. No more redundancy.
Getting Started
Want to test and document APIs without the repetition mess?
Download the offline app from voiden.md and set up an API repo.
Create a couple of .void files, one per endpoint you’re testing.
- Alternatively, import your existing Postman collection.
Detect the bits that can be reused, and extract them by following the steps provided above.
Execute endpoints in Voiden and validate responses.
Sounds like a good step towards simplifying API tooling workflows? Join our GitHub Discussions to share feedback and shape Voiden.
Related Posts

Aldin
Why API tooling needs a reset (and what we're doing about it)
Building and testing APIs feels all over the place nowadays. It's a pain, it wastes time, causes errors, and frustrates everyone involved. This post dives into why API tooling is such a headache, why the industry keeps making it worse, and how Voiden makes life easier for developers.

Aldin
How to test and document an API without ever leaving the editor
Tabbing between browser pages, Postman, and doc platforms for API testing and documentation creates stale docs and kills productivity. Voiden's markdown-style files let you spec, test, and document APIs offline in one place, using a Git-based workflow you already know, without ever having to leave the editor.

Aldin
Keep API Work Local: Why Offline-First Beats Cloud-Based Tools?
Cloud-based API tools like Postman can expose your data, and leave you stuck when servers fail or docs lag. Offline tools won't.