DEV Community: Nikolas Dimitroulakis

How Should an API Client Look in 2026? A Comparison of the Field

Nikolas Dimitroulakis — Tue, 23 Jun 2026 08:23:08 +0000

API tooling is having a rough year, and that's actually the interesting part.

Postman killed free teams in March. Insomnia forced cloud sync in v8 and is still rebuilding trust. Bruno is absorbing most of the migration wave. And a handful of smaller tools are betting the whole category has been building the wrong abstraction since day one.

I spent the last few weeks actually using seven of these tools on the same real workflow: REST and GraphQL requests, env vars across staging and prod, auth, and docs that are supposed to stay in sync with the requests they describe. Here's where each one actually stands.

The real architectural split

Most comparisons line up feature checkboxes: offline, yes/no; Git integration, yes/no. That misses the real fault line in the category, which isn't a feature. It's where your API definitions actually live.

Workspace-centric tools (Postman, Insomnia, Hoppscotch) store collections inside the app's own data model. You can export them, sync to Git, even self-host the sync layer. But the source of truth is the app's internal state. The export is a snapshot, not the real thing.

File-centric tools (Bruno, Voiden, Yaak, in different ways) store collections as actual files on disk, read directly by Git, your editor, and CI, with no export step. The file is the source of truth.

Open source matters here too, and not as a checkbox. A closed-source tool can disappear, get acquired, or change its pricing model overnight, and your only option is to migrate. Every open-source tool below can be forked, audited, or kept alive by the community if the maintainers walk away. That's a real, structural advantage worth weighing on its own, separate from whatever feature set a tool ships with this month.

The field at a glance

Tool	Open source	Architecture	Format	Best known for
Voiden	✅ Apache 2.0	File-centric, git-native	Markdown (`.void`)	Composable blocks, readable without the app
Postman	❌	Workspace-centric, cloud-first	Proprietary	Richest feature set, MCP integration
Insomnia	✅ Apache	Workspace-centric, cloud sync (v8+)	Proprietary	GraphQL heritage, Kong backing
Hoppscotch	✅ MIT	Web-first	Proprietary	Largest FOSS star count, browser workflow
Bruno	✅ MIT	File-centric, git-native	Bru Lang (proprietary)	Community momentum, fast release cadence
Yaak	✅ MIT	File-centric, git-friendly	Proprietary	Minimal, intuitive design, Tauri/Rust stack
curl	✅ MIT	No GUI, no collections	N/A	The universal baseline, scriptable, everywhere

Postman

Still the default for teams that haven't migrated, and still genuinely capable: the richest feature set here, an established MCP integration for agent workflows, tooling most developers already know. Open source: no. The free-team removal in March 2026 was a real breaking point, and the cloud-first model means your definitions live on Postman's infrastructure, not yours.

Insomnia

Real GraphQL-first heritage and Kong's backing. Open source under Apache, which is a genuine point in its favor. But forcing cloud sync in v8 cost it real community trust that hasn't fully come back, and Git sync is an add-on to a cloud-first design, not the actual architecture.

Hoppscotch

The largest open-source star count in the category, MIT licensed, and a genuinely good browser-based workflow. Also the clearest example of a different category: web-first, not file-centric, not really part of the offline/git-native model the rest of this list is about.

Bruno

The closest direct competitor to the file-centric model. Real community momentum, a fast release cadence, MIT licensed, genuinely offline-first and git-native: .bru files on disk, no export, no account. The real gap: .bru is a proprietary format. A .bru file means nothing without Bruno installed. No plugin SDK yet either, despite it being the single most-requested feature on its tracker.

Yaak

Built by the same person who built and sold Insomnia, and it shows: Yaak's whole pitch is design restraint, doing less, staying out of your way, instead of stacking on more features. MIT licensed, built on Tauri and Rust rather than Electron, which gives it a noticeably lighter footprint than most of this list. It mirrors workspaces to your filesystem for Git, so it's file-centric in practice, but its actual differentiator isn't the file format, it's the interface itself: minimal by default, with depth available only when you go looking for it. Worth watching, with one real caveat: community contributions are currently limited to bug fixes, not new features, so its roadmap is more centrally controlled than Bruno's or Voiden's.

curl

Not really in the same category, and worth including anyway, because it's the baseline everyone else is implicitly compared against. No GUI, no collections, no environments as a concept. Just a request, scriptable, in every CI pipeline and every dev's muscle memory. Nothing here replaces curl for a one-off request; the entire point of the other six tools is managing the complexity curl doesn't try to solve.

Voiden

Same file-centric premise as Bruno, with two real differences: the format is plain Markdown, not a proprietary DSL, and the request itself is built from composable blocks instead of a fixed form. A .void file is readable in any editor, on GitHub, in a PR, with zero dependency on Voiden being installed. Headers, auth, and params are reusable blocks, not duplicated fields. Apache 2.0 licensed. The honest gap: a much smaller community right now than Bruno or Hoppscotch, since the category itself is still young.

There's a short demo comparing Voiden and Postman side by side on the same request if you want to see the workflow difference instead of just reading about it. ⬇️

https://youtu.be/mpMarhwODY4

Try Voiden here: https://voiden.md/download

So which one should you actually use?

No clean winner, because the field is genuinely split on what people are optimizing for.

Need the deepest feature set and already have a working Postman flow? The migration cost might not be worth it yet.

Want file-centric and git-native with the largest existing community today? Bruno, with the tradeoff that your files are tied to its own format.

Want the same file-centric model with a lighter footprint and a deliberately minimal interface? Yaak, with the tradeoff that the roadmap is more centrally controlled right now.

Want files that are readable without the tool installed, real composability instead of fixed forms, and you're fine being on a younger, smaller project? Voiden.

And if you just need to fire off one request without installing anything? curl was already enough.

The actual story of 2026 isn't that one tool won. It's that "where do your API definitions live, and who can keep the tool alive if the maintainers disappear" became real questions instead of implementation details nobody thought about.

Star counts, license status, and contribution policies above reflect late May 2026 and move fast; check each project's repo before deciding based on community size alone.

Modern API Tooling: An 11-Principle Scorecard

Nikolas Dimitroulakis — Fri, 19 Jun 2026 23:59:48 +0000

A while ago I came across a really good article on the future of API tooling:

https://efp.asia/blog/2025/12/24/api-tooling-crisis/

It lays out a set of criteria for what modern API clients should look like:

Local-first, filesystem-centric: collections and requests live directly in the project repo
Support for OpenAPI specs and GraphQL schemas, plus straightforward testing
Zero login wall: works fully offline without accounts or mandatory cloud sync
Git-native collaboration: uses version control instead of proprietary cloud workspaces or seat licenses
Native performance: built with high-performance tech (e.g. Rust), not browser wrappers
Extensible design: modular plugin architecture that doesn’t bloat the core
Universal imports: OpenAPI, GraphQL, Postman collections, etc.
Proxy agnostic: works cleanly with interception tools like Charles or mitmproxy
Scripting and auth flows: pre-request and post-response hooks
Straightforward testing: built-in code-based testing of API responses

I agree with all of these. The only thing I’d add is pricing as another important dimension.

Recently I was experimenting with a pricing MCP and decided to run a quick test: evaluate all the API clients I know against these criteria using https://pulse.pricingsaas.com/.

Scoring was simple:

Each principle is rated 0 (missing), 1 (partial), or 2 (fully met). Final score is normalized to a 10-point scale.

Overall rankings (out of 10)

Bruno — 8/10
Voiden — 8/10
Yaak — 7/10
Insomnia — 6/10
cURL — 6/10
HTTPie — 5/10
Postman — 5/10
Requestly — 5/10
Hoppscotch — 4/10
Apidog — 4/10

Key takeaway: no perfect API client yet

Every tool fails on at least a few of the 11 principles, so none fully matches the “ideal” API tooling model. The ceiling right now seems to be around 8/10.

What separates the top tools (Bruno, Voiden, Yaak)

The strongest tools tend to share a few traits:

Local-first, filesystem-based storage
Git-native collaboration
No forced login (or minimal account gating)

Where they still fall short is usually native performance, since most GUI tools are built on Electron.

A few structural patterns across the space

Electron is the default weakness Most GUI tools (Bruno, Insomnia, Postman, Requestly, Hoppscotch, Apidog) rely on Electron. The only real exception is Yaak, which uses Tauri + Rust and is much closer to true native performance.
Zero-login is a clear dividing line Several major tools are effectively excluded because they require accounts: Postman, Insomnia, Hoppscotch, Apidog.
Pricing is becoming a core constraint Most tools are increasingly account-gated or paid-tier driven. Voiden stands out as fully free with no tiering, while Postman is heavily penalized due to its pricing model and limited free tier.

Tool-level notes (high level)

Bruno: strong balance of scripting, testing, and Git-native design, but held back by Electron
Voiden: most aligned overall, especially due to being fully free and extensible
Yaak: best native performance, but lacks scripting and testing
Insomnia: strong feature set, but weakened by login and pricing dependence
Postman: best-in-class scripting and testing, but cloud-first and heavy
cURL / HTTPie: great primitives, but not full API design environments

Final insight

The ideal API client would likely combine:

Yaak’s native Rust performance
Voiden or Bruno-level scripting, testing, and Git-native workflows
Right now, the space is split between:
Local-first developer tools (Bruno, Voiden, Yaak)
Cloud-first enterprise platforms (Postman, Apidog, Hoppscotch, Insomnia)

Full results here: https://share.pricingsaas.com/reports/ps_-1DO_vX/20260619_220350_52a40f15/api-client-scorecard-v5.html

Voiden : offline API client, Git-native, Markdown-based. Looking for contributors in TypeScript/Electron/plugin development.

Nikolas Dimitroulakis — Mon, 25 May 2026 11:17:47 +0000

Hey there,

Bit of context first: I am a member of a 30 people+ team and most API clients we used felt like they were built for a different job than what we actually did.

Our team lives in Git, our communication is happening on slack, our docs written and maintained on confluence and after some time they always drift away from the actual requests inside Postman.

So we built and open sourced Voiden a few months ago: an API tool where all that: specs, tests, context and docs are always together in the same executable plain text file (markdown). We also made this Git native so that every change is versioned and tracked just like code.

The last change we have made is to add a Runner so that one can run the files directly from the terminal and CI/CD pipelines.

here is the tool: https://voiden.md/download

repo: https://github.com/VoidenHQ/voiden

Looking for contributors in TypeScript/Electron/plugin development.

Good first issues:
https://github.com/VoidenHQ/voiden/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22

and a discussion:
https://github.com/VoidenHQ/voiden/discussions/386

Cross-Platform Desktop Wars: Electron vs Tauri: How do you explain the tradeoffs to users?

Nikolas Dimitroulakis — Wed, 25 Mar 2026 14:59:25 +0000

Hello,

I am writing cause I wanted to get some opinions from folks here that have actually built and shipped with Electron (or Tauri).

Background: Building an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior - not the typical form centric behavior that postman or others have: local workflows, richer interactions, and some things that honestly would have been much harder for us to build and iterate on this quickly in a more constrained setup. Thats why Electron.

this is the tool:

https://github.com/VoidenHQ/voiden

Now, as adoption is growing, we are starting to get the usual questions about memory footprint and app size.

The (slightly) frustrating part is this:

When the app is actually being used, the app-side memory is often pretty reasonable. In many normal cases we are seeing something like 50–60 MB for the actual usage we care about (even added it in the app itself for people to check it out).

But then people open Activity Monitor, see all the Chromium/Electron-related processes, and the conversation immediately becomes:

“yeah but Tauri would use way less”

And then, without realizing, I suddenly end up talking and philosophizing about Electron, instead of discussing the tool itself (which is what I am passionate about :)

And of course, I get it. The broader footprint is real. Chromium is not free. Electron has overhead. Pretending otherwise would be foolish. So we are constantly optimizing what we can, and we will keep doing so…

At the same time, I do feel that a lot of these comparisons feel weirdly flattened. For example people often compare:

full Electron process footprint VS the smallest possible Tauri/native mental model

…without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others. Which is by the way the reason that we went with Electron.

So all this context to get to my real question, which is:

How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?
And also, for those of you who have had this conversation a hundred times already:

What do you say when people reduce the whole discussion to “Electron bad, Tauri good”?

Have you found a good way to explain footprint in practical terms?

Where do you think optimization actually matters, vs where people are mostly reacting to the idea of Electron?

Mostly trying to learn how others think about this , especially those who have built more serious desktop products and had to answer these questions in the wild.

Would love your thoughts and advice!

Burgers, APIs, and the State of Developer Marketing

Nikolas Dimitroulakis — Fri, 13 Mar 2026 13:43:13 +0000

Wanted to share some thoughts as a founder who has been building and shipping developer tools and applications (including open source, Voiden).

When I started, every discussion and engagement I had with dev-tool marketers and experts revolved around the idea that effective developer marketing should be a combination of genuinely helpful content, engaging tutorials, thoughtful blog posts, and insightful guides that actually help people get unblocked or see common problems from a new perspective.

I wanted to — and still want to — contribute to that kind of ecosystem.

And to be clear, I still believe this is what good developer marketing looks like.

But I also realized that a lot of what passes for “dev marketing” today (especially in the API tooling space that I’m in) is much more about SEO, keyword stuffing, backlinks, and thinly veiled sponsored content.

Case in point:

I came across a post on dev.to titled:

“12 open-source alternatives to popular dev tools.”

Great idea, right?

Except the first tool listed wasn’t open source at all — it’s a paid SaaS.

Some of the “alternatives” weren’t even truly comparable. It felt much more like keyword stuffing and backlinking than a genuine resource meant to help developers.

And some of the comments below were things like:

“Great list!”

So I made a joke in the comments calling out the issue. Something along the lines of:

“You could also add the tool to a list of ‘Top burger joints in Manhattan’, since people could also test APIs while eating a burger, right?” or something like that.

In hindsight, maybe not the best joke ever made.

The author of the post apparently thought the same and deleted my comment.

Twice.

But this isn’t really about that one tool or that one post.

I have seen many companies do similar things.

That said, I also don’t want to overgeneralize and in a weird way I can even sympathize a bit.

A lot of founders and makers fall into a strange trap: the idea that self-promotion is inherently bad.

So instead of honestly sharing what they’ve built or what they’ve learned, they look for clever tactics or “growth hacks” to appear neutral, helpful, or educational while still getting attention.

In a way, they’re staging the play they think developers want to see.

It’s understandable (maybe).

But it can easily cross the line into something misleading or manipulative.

I honestly don’t know whether this happens because people underestimate developers’ ability to see through it, or because the SEO benefits eventually pay off anyway.

Maybe both.

From my experience, developers are skeptical and notoriously allergic to being marketed to. And when marketing stretches the truth this far, it can slowly erode trust — not just in one tool, but in the ecosystem as a whole.

The lesson I’m taking away as a founder:

Authentic engagement wins.

Build tools that solve real problems.
Share honest insights.
Be simple and transparent about what you are doing.

A little vulnerability goes a long way.

Anyway, enough whining.

Let’s make it fun:

What’s the most absurd developer marketing you’ve seen lately that made you roll your eyes?

Voiden is now extensible via community plugins

Nikolas Dimitroulakis — Tue, 10 Mar 2026 21:07:09 +0000

A lot of developer tools follow the same pattern: They start simple and then new ideas come. Then these these new ideas become built-in features.

This is of course fine (and natural) but over time, the core can become huge, harder to maintain and evolve, and slower to experiment with.

When we started building Voiden we wanted to avoid this trap.

What we observed from our experience and also while talking to other developers is that different teams use API tools very differently, in different scenarios.

So we decided that forcing everyone into the same giant feature set doesn’t really make sense.

So, instead of putting everything in the core, we decided to have the tool grow through a plugin system. This way, it can be flexible and extensible since new functionality can live outside of the core tool.

The idea is simple:

Keep the core lean. Let the ecosystem grow around it. Developers can build extensions independently and users can just install the pieces they actually need.

Keeping Voiden flexible and extensible is one of the key design principles we had from day one and I am very happy with this milestone.

Curious what kinds of extensions people will build 🙂 (we already have a few community plugins in the works)...

Start contributing: https://docs.voiden.md/docs/plugins/build-a-plugin
Repo here: https://github.com/VoidenHQ/voiden

API security and compliance in 2026

Nikolas Dimitroulakis — Fri, 06 Mar 2026 10:22:05 +0000

Choosing an API based on functionality is one thing. Getting it approved for production is where things can get tricky.

The moment your product sends data to a third-party service, questions come up:

→ Where is the data stored?
→ How long is it retained?
→ Are third-party processors involved?
→ Is it compliant with GDPR, SOC 2, or other standards?

This is often the step that slows down adoption more than the integration itself.

At ApyHub, we tackle this head-on.

Every API in our catalog comes with clear, standardized info on data handling and compliance. That means teams can:

→ See certifications and disclosures upfront (GDPR, SOC 2, ISO 27001)
→ Understand exactly where and how data is stored and handled
→Track retention and third-party processing
→ Stay up-to-date as APIs evolve

The result? Teams can find, evaluate and approve APIs faster, with confidence, without digging through scattered docs or privacy policies.

We are happy as our catalog keeps growing with new APIs. But in the end, it’s not just about functionality.

It’s about trust, compliance, and true data sovereignty.

Explore certified APIs here: https://apyhub.com/catalog

Scripting in API tools?

Nikolas Dimitroulakis — Tue, 24 Feb 2026 17:43:38 +0000

Spent months thinking about scripting in API tools.

Honestly, most tools don’t go far enough. They stop at JavaScript, a limited sandbox and a system that is not really extensible.

That works for small tests, but it can also quickly break down when you want to start building real, multi-step workflows.

We wanted to go further. So we spent time observing how developers actually work with APIs, talking to them, and learning from the patterns and frustrations in real workflows. We saw token rotations handled manually, small helper scripts scattered across repos, and tools that forced engineers into JavaScript even when their stack was Python, Go etc.

So for Voiden Pre & Post Request Scripts adapt to how developers work.

JavaScript + Python (first-class): use the language you already know and trust
Real runtimes & package imports: run actual code, import libraries, reuse existing logic
Stateful workflows: share variables, store data, and chain requests dynamically
Orchestration-ready: automate multi-step flows, token rotations, and dependent API calls

Again, it's a basic principle we had from day 1: API tools should not dictate how devs think. It should adapt to how they work.

We believe this is one of the most powerful scripting systems available in any API client today.

And we are just getting started.

🌐 Beta: https://voiden.md/download#beta
📂 GitHub: https://github.com/VoidenHQ/voiden

Assertions vs pre and post scripts

Nikolas Dimitroulakis — Tue, 24 Feb 2026 17:39:06 +0000

Simple Assertions vs Pre & Post Requests

Many developers already use Assertions in Voiden to validate responses—checking status codes, verifying fields, or ensuring data formats.

They are great for simple validation and quick checks after a request.

But what if your workflow needs more than validation? That’s where Pre & Post Request Scripts come in.

Pre-request scripts run before the request: generate tokens, set dynamic headers, compute values, inject variables, or prepare data on the fly.

Post-request scripts run after the response: validate responses, extract values, store variables, trigger follow-up logic, or chain multiple requests together.

When to use Assertions: simple checks and validations, fast feedback, lightweight workflows.

When to use Pre & Post Scripts: dynamic APIs, token rotation, multi-step flows, automated chaining, or when your workflow requires more complex logic.

Use assertions for quick checks and scripts for dynamic, automated workflows.

Voiden now supports JavaScript and Python for Pre & Post Request Scripts (available in the beta, link below).

Question for the community: Which other languages would you like to see supported in Voiden?

Your feedback could shape the next updates!

🌐 Beta: https://voiden.md/download#beta
📂 GitHub: https://github.com/VoidenHQ/voiden

Most API tools treat requests as monolithic blocks - Voiden doesn't

Nikolas Dimitroulakis — Mon, 16 Feb 2026 09:57:50 +0000

On the one side you have legacy tools: API tools like Postman, Insomnia etc that are built as platforms first: Accounts, workspaces, cloud sync, dashboards, paywalls. Actual API work often comes second.

On the other side, we now have a bunch of API tools that are vibe coded. Built, shipped and posted on Twitter the same day. Yes, they look sharp, but under the surface they are often thin abstractions over fetch calls. With no clear model or long-term thinking about workflows, versioning, or how teams evolve their API usage over time.

Somewhere in between, there is Voiden. Voiden is a result of years of synthesizing thoughts and feedback from real developers : backend engineers, platform teams, API designers. We watched how they actually work. Where workflows break. Where collections rot and collaboration becomes painful.

So we designed it, we showed it, we improved it and then improved it a bit more. And now we open sourced it.

Voiden is an offline-first, Git-native API tool where requests, specs, tests, and docs live together as executable Markdown inside your repository.

Voiden introduces a live Markdown + API runner workflow. API requests, reusable blocks, and human explanations live in the same Markdown file - and can be executed in place. No request builder UI. No context switching.

The best thing is, while other tools treat a request as a single opaque object, Voiden does something completely different (and unique) - no other API client does this.

Voiden breaks a request into composable blocks: endpoint, headers, query, JSON, auth etc.In most tools, headers and auth live inside individual requests, so if you need them elsewhere, you duplicate them. When something changes, you update every copy manually.

In Voiden, blocks behave like functions: define them once, reference them across requests, and when the block changes, every request using it stays in sync.

Voiden is intentionally lightweight and extensible. We wanted the core to stay lean, and everything else to live in a plugin system: gRPC, GraphQL, WebSockets (WSS), assertion blocks, etc and more coming.

That means the tool can grow in capability without growing in bloat. Everyone can select which plugins to have and the community can extend it just as easily as we can.

Voiden works around your workflow, your way, rather than make you adapt your processes around the tool.

If you don't want to deal with bloated API tooling and saas looking clients, Voiden is the tool you want to try.

Github : https://github.com/VoidenHQ/voiden

How to switch from Postman to Voiden : https://voiden.md/blog/migrate-postman-collections-to-voiden

which API tool is this?

Nikolas Dimitroulakis — Tue, 10 Feb 2026 07:14:51 +0000

Postman announced that their Free plan for teams is going away.

Nikolas Dimitroulakis — Thu, 05 Feb 2026 11:14:53 +0000

Postman announced that their Free plan for teams is going away.

Free now means one person. Collaboration is a paid upgrade.
This is not really a surprise. It’s the SaaS playbook.

That’s exactly the problem we didn’t want to recreate when we built Voiden.

Voiden doesn’t have “Teams” cause Git already solved it years ago.

Your team structure already exists.
Your review process already exists.
Your version history already exists.

So instead of inventing roles, dashboards, and pricing tiers, Voiden:

keeps API specs as Markdown in your repo
uses commits and PRs for collaboration
works fully offline
never locks a teammate out because of a license

APIs belong with the code. Collaboration belongs in Git. Everything else is overhead, and usually a paywall.

And yes, we have now open sourced Voiden.
https://github.com/VoidenHQ/voiden