API Design & Testing Tools 2026 — Bruno / Insomnia / Postman / Hoppscotch / Scalar / Mintlify / Buf Deep Dive

Prologue — "I can't use Postman anymore"

A real Slack message from 2025: "The new Postman version forces sign-in, my collections auto-synced to the cloud, and security shut us down. Recommendations?"

Fifty replies. Bruno, Hoppscotch, Insomnia (old version), Yaak, Apidog. Five years ago the question "what else is there besides Postman?" would have felt strange. In 2026 the opposite is true. Not using Postman is the new default for many teams.

It is not just one company's policy change. The whole API tooling market has been re-sorted. Postman → Insomnia → Bruno is a clear arc toward "off-cloud, off-account, off-lock-in." OpenAPI viewers moved from Swagger UI to Redoc to Scalar. Docs: ReadMe and Mintlify turn an OpenAPI spec into a hosted developer portal. gRPC: Buf is the de facto toolchain. And AI shows up everywhere — Postbot and Insomnia AI generate requests from natural language and explain responses.

This post draws the map of API design and testing tools as of May 2026. Four buckets — clients, docs, design, gRPC — then a final question: which tool fits your team?

1. The 2026 API tooling map — four buckets

The big picture. Most tools blur category lines, but if we sort by core value proposition we get four clusters plus a few cross-cutting categories.

The taxonomy is messy because tools overlap. Postman does client + mocking + docs + gRPC + AI. Bruno focuses on client + lightweight design + git-based sync. Apidog tries to do design + client + docs + mocking in a single product.

When picking, look at two things.

1. Core value: requests? spec design? docs?
2. Data ownership: local files? cloud? git?

Point 2 is the 2026 fault line. The Postman drama drove a "my data on my filesystem" movement that produced Bruno, Yaak, and Insomnia's file-based mode. Reducing cloud dependence is a clear market direction.

2. Bruno — winner of the file-based wave

The fastest-growing tool of the cohort. Started in 2021, raised a Series A in 2024. One-line summary: every collection is just files; commit them to git.

Why it took off

The single key differentiator: collection = file tree. Postman wraps a collection in one big JSON blob that auto-syncs to the cloud. Bruno stores a collection as a directory and each request as a .bru file.

my-api/
  bruno.json
  environments/
    dev.bru
    prod.bru
  users/
    list-users.bru
    create-user.bru
  orders/
    get-order.bru

Each .bru is human-readable text.

meta {
  name: List Users
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/users
  body: none
  auth: bearer
}

auth:bearer {
  token: {{authToken}}
}

Why does this matter? git diff becomes meaningful. In a PR review, "this request added a header" is visible at a glance. To see the same change in a Postman export, you stare at a JSON blob diff. API collection changes become reviewable like code changes.

Side effects: you can branch and merge. You can receive collection changes as PRs. You can lint collections in CI. That is the real value of file-based.

Features

• HTTP/REST client (on par with Postman/Insomnia)
• gRPC client (added 2024)
• GraphQL
• WebSocket / SSE
• Scripts (pre-request, post-response, JavaScript)
• Environment variables (per-environment .bru file)
• Secret management (.env.local, git-ignored)
• CLI (bru run) — execute collections in CI
• OpenAPI import / export

Weaknesses

• Team sharing is bound to git — half the appeal evaporates without git
• gRPC support is not yet on par with Postman or Kreya
• Design mode (spec-first) is weak — Stoplight/Apidog territory
• Teams that need cloud sync need a paid add-on

Who should use it

• Engineering teams with established git workflows
• Teams that want to review API collections as PRs
• Companies for which sending data to external SaaS is a compliance problem
• Also fine for a solo dev who just wants a fast client

Bruno's pitch: "Collections are code. If you already have git, why pay for another SaaS?"

3. Insomnia (Kong) — two trust crises

Insomnia was once the beloved Postman alternative. Light, clean, worked offline. Kong acquired it in 2019, and what happened next split the timeline.

The 2023 crisis — Insomnia 8 forced login

The August 2023 Insomnia 8 release sparked a major backlash. The new version effectively required login and tried to migrate local data into a new cloud-sync model. Some users reported data appearing in the cloud without explicit consent.

The community erupted. GitHub issues collected hundreds of comments. Many users downgraded to Insomnia 7.x or jumped to Bruno. Kong apologized, added Scratch Pad mode (use without an account), and committed to changing the migration model.

2024–2025 recovery

Kong since then:

• Local Vault mode — keep all data local
• Kept the Apache 2.0 license
• Strengthened gRPC, GraphQL, WebSocket
• Insomnia AI — response to Postbot

Still a strong product. Its Kong Konnect gateway integration is unmatched by any other client. But trust, once lost, returns slowly.

2026 assessment

• Polished single-tool experience
• Natural choice for teams already on Kong Gateway / Konnect
• File-based git workflows are weaker than Bruno
• The "will they force cloud again?" worry has not fully gone away

Who should use it

• Teams on Kong Konnect / Kong Gateway
• Solo devs who find Postman heavy but Bruno's git-only model awkward
• Teams that want to cover REST + gRPC + GraphQL + WebSocket in one tool

4. Postman — the giant's shadow, betting on AI

Postman is still the biggest company by far. Over 25 million users, a 5.6 billion dollar valuation after Series E in 2021. But the mood has clearly shifted.

The 2023 trust crisis

In May 2023 Postman v10 hinted at the future deprecation of Scratch Pad — meaning the no-account mode would be phased down. Combined with the fact that collections live in the Postman cloud by default, enterprise security teams ruled it out: customer API keys and payloads sitting in an external SaaS was a non-starter.

The result:

• Bruno user count exploded
• Insomnia got a second wind
• Hoppscotch self-hosting picked up
• Yaak and Apidog showed up as new entrants

Postman eventually kept Scratch Pad and re-emphasized local options. But the "cloud by default" perception stuck.

Postbot — the AI bet

Postman bet hard on AI. Postbot:

• Generate a request from natural language ("get my repo list from the GitHub API")
• Auto-generate tests (read the response, write assert statements)
• Explain a response ("what does this JSON mean?")
• Debug assistance (why did I get a 401?)

In the GPT-5 / Claude 4.x era, AI is more table stakes than differentiator. But Postman has an enormous context — collections, history, environments — that lets the AI produce noticeably better outputs than a stand-alone AI in another tool.

Feature breadth is still the widest

• REST, GraphQL, gRPC, WebSocket, SOAP
• Mock servers
• Public API Network (marketplace)
• Monitors (scheduled collection runs)
• Newman CLI (run collections in CI)
• Postman Flows (visual workflows)
• Postman Live Collaboration
• Postman Insights (org-wide API analytics)

Weaknesses

• Heavy desktop app (Electron, sometimes gigabytes of RAM)
• Cloud-default and collection sync cause compliance friction
• Pricing — team tiers are pricey compared to alternatives
• git-diff friendliness is poor

Who should use it

• Large teams that need the broadest feature set (REST + gRPC + mock + monitor in one place)
• Companies that want to publish their public API on Postman Public API Network
• Organizations where Postman is already standard and migration cost is high

5. Hoppscotch — fully open-source, self-host friendly

Hoppscotch is an open-source API client out of India. Started in 2019 (originally Postwoman; renamed after trademark issues). Core: fully open source, runs in the browser instantly, self-hostable.

Differentiators

1. PWA / web-first — use it in the browser right now at hoppscotch.io. No install.
2. Apache 2.0 open source — the core is genuinely open, self-hostable
3. One-line Docker self-host — enterprises can run it on their own infra
4. Fast — Vue based, lightweight
5. Local storage — defaults to browser IndexedDB

Features

• REST, GraphQL, WebSocket, SSE, MQTT, gRPC
• Environment variables, collections
• Pre-request / test scripts
• Team sync (Hoppscotch Cloud or self-host)
• Hoppscotch Agent (desktop helper for CORS bypass)

Weaknesses

• Narrower feature set than Postman or Insomnia
• A desktop build exists, but the web-first design occasionally feels awkward
• Team collaboration needs cloud or self-hosted infra
• gRPC was added relatively recently and is less polished

Who should use it

• Open-source absolutists, orgs where self-host is policy
• A solo dev who wants a fast, no-install client
• When you want to share with a teammate as a browser link, immediately
• Companies in India and Southeast Asia (large local community)

6. Stoplight Studio (SmartBear) — design-first that stalled

Stoplight Studio was once the leading API design-first tool (write the OpenAPI spec before any code). Visual editor for OpenAPI, auto-generated mock servers, hosted docs. SmartBear acquired Stoplight in 2023.

Post-acquisition stall

SmartBear owns a wide API portfolio — Swagger UI (the original), SoapUI, ReadyAPI. The Stoplight acquisition was a natural fit, but post-acquisition Stoplight Studio development visibly slowed. The community wondered: "Will Stoplight, like every other tool in SmartBear's catalog, become an enterprise sales vehicle?"

As of 2026, Stoplight Studio:

• Still one of the most complete visual OpenAPI editors
• Spectral (OpenAPI linter) is effectively the standard — used by Redocly, Bruno, GitHub Actions, everywhere
• Prism (mock server) is also still the standard
• But new-feature cadence has lost ground to upstarts like Scalar and Apidog

Who should use it

• Teams where non-engineers (PMs, designers) co-edit OpenAPI specs
• Enterprises that already have SmartBear licensing
• Spectral / Prism are worth using regardless of which client tool you choose

7. Scalar — the rising star OpenAPI viewer

Scalar appeared in 2023 and shook up the OpenAPI viewer market. Raised a seed in 2024 and a larger round in 2025. Core message: "Swagger UI is ugly, Redoc is too static. Let us rebuild it."

Why it took off fast

1. Design quality — UI that matches 2026 design trends
2. Dark mode, keyboard shortcuts, search — Postman-grade UX
3. Live requests — call the API from the docs page
4. Vue / React / Hono / Express integrations — one line of code mounts it
5. Open source (MIT) — self-hosting friendly

Usage pattern

// Hono example
import { apiReference } from '@scalar/hono-api-reference'

app.get(
  '/reference',
  apiReference({
    spec: { url: '/openapi.json' },
  })
)

That is it. One line in the backend gives you a Scalar UI for your OpenAPI at /reference.

Scalar vs Redoc vs Swagger UI

Who should use it

• Teams that want a polished public doc site for a new API
• Teams tired of Swagger UI's dated look
• Teams that want users to call the API straight from the docs

8. Redoc / Redocly — open-source viewer plus commercial CLI

Redoc has long been recognized as one of the cleanest OpenAPI viewers. Since 2024 Redocly (the company) has invested in paid tooling: CLI, linter, portal.

Two branches

1. Redoc (open source, MIT) — single-page OpenAPI viewer
2. Redocly CLI (commercial) — multi-spec portal, linter, bundle, OAS-to-website

Characteristics

• The 3-pane layout has become the de facto standard for OpenAPI docs
• Holds up well for big specs (100+ endpoints)
• Stripe, Docker, Twilio and other large API docs use Redoc or a Redoc-derived setup
• Free Redoc has no live request — only Redocly paid

Who should use it

• Teams with very large OpenAPI specs (hundreds of endpoints) that need static docs
• Teams that want the classic Stripe-style 3-pane layout
• Companies that want a multi-spec dev portal via commercial Redocly CLI

9. Swagger UI — the classic, still alive

The original. Started in 2011, acquired by SmartBear and donated to the OpenAPI Initiative. Almost every backend framework ships a one-liner that mounts Swagger UI (FastAPI, Spring, NestJS, Express, ...).

Why it is still used

• Dev-time default — FastAPI's /docs, NestJS @nestjs/swagger, etc.
• try-it-out button is the most familiar pattern
• Every backend framework auto-mounts it
• Apache 2.0

Weaknesses

• Same design as 2014
• Slows down on big specs
• Weak search
• Limited mobile/tablet friendliness

Who should use it

• Internal dev/debug docs where switching to Scalar is not worth the lift
• Teams happy with whatever the framework mounts by default

10. Mintlify / ReadMe.com — two doc SaaS heavyweights

This category promises "turn an OpenAPI spec into a full-stack developer portal."

Mintlify

• Started 2022, fast growth through 2024
• MDX-based docs
• OpenAPI auto-import, auto-generated API reference pages
• Full-text search (with AI chat UI)
• GitHub integration — markdown/MDX changes in a repo auto-publish
• Paid (startup and enterprise tiers)
• Used by Stripe, OpenAI, Anthropic, and others

ReadMe.com

• The older heavyweight (started 2014)
• API reference, guides, changelog, search in one place
• Powerful try-it console
• Metrics — track which endpoints get called
• Developer Dashboard — per-developer key management
• API usage analytics — call volume trends in a dashboard

Mintlify vs ReadMe

Who should use it

• Companies with public APIs used by external developers
• Teams that want to manage docs through GitHub PRs (Mintlify)
• Teams that want per-developer keys and usage dashboards (ReadMe)

11. Buf — the de facto standard for the Protobuf / gRPC ecosystem

While the REST tooling world has been thrashing, the gRPC/Protobuf world has settled on a clear standard. Buf.

What Buf did

Protobuf is powerful but its tooling was scattered — protoc was hard, there was no dependency management, no linter. Buf bundled the following:

• buf build — fast .proto compile
• buf lint — style and best-practice checks
• buf breaking — auto-detect schema breakage (essential in CI)
• buf format — .proto formatter
• buf generate — run protoc-gen-* plugins from yaml config
• Buf Schema Registry (BSR) — Protobuf's npm/pypi equivalent

The most useful CI line

# .github/workflows/proto.yml
- run: buf lint
- run: buf breaking --against '.git#branch=main'

These two lines automatically block "style violations" and "changes that break existing clients" in PRs. A safety net every team running Protobuf in production should enable.

Buf Connect

Buf's own RPC protocol. Supports gRPC, gRPC-Web, and Connect protocol from the same codebase. You can call gRPC from the browser using fetch. Clean TypeScript/Go/Kotlin clients.

Who should use it

• Every team running Protobuf/gRPC in production — basically required
• Companies where multiple teams share schemas (BSR for dependency management)

12. gRPCurl / Kreya — gRPC clients

Actually invoking gRPC needs its own tools (like curl for HTTP).

gRPCurl — CLI

grpcurl -d '{"name": "world"}' localhost:50051 helloworld.Greeter/SayHello

The gRPC version of curl. With server reflection enabled it pulls the schema automatically. Used in CI scripts, debugging, and ad-hoc calls. Not an official grpc-project tool — maintained by fullstorydev.

Kreya

A GUI gRPC client. Beyond simple calls:

• Streaming (server-side, client-side, bidirectional)
• Protobuf import (BSR/local)
• Environment variables, collections, scripts
• Also supports REST/GraphQL (every protocol in one place)

Postman and Insomnia both support gRPC, but if you need the precision of a gRPC-dedicated tool, Kreya is usually smoother.

gRPC support in Postman / Insomnia / Bruno

• Postman gRPC — reflection, .proto import, streaming all work; widest coverage
• Insomnia gRPC — area Kong has invested in, works well
• Bruno gRPC — added 2024, basics work but streaming UX is still rough

Who should use what

• gRPCurl — debugging, CI scripts, ad-hoc calls
• Kreya — backend devs who touch gRPC every day
• Postman/Insomnia — teams that want gRPC and REST in one tool

13. Apidog / Yaak / Bambda — three upstarts

New tools from the last two years. All three aim for the gap between "Postman is heavy" and "Bruno is git-only."

Apidog (from China)

• Design + client + mock + docs + automation in one tool
• The ambition of combining Stoplight + Postman + Mintlify
• Generous free tier
• AI features (design endpoints from natural language)
• Downsides: UI a bit busy, some translations rough
• Who: teams that want one tool to rule them all, where Postman pricing hurts

Yaak (Rust based)

• file-based philosophy like Bruno
• Built with Rust and Tauri, lighter than Electron
• Indie tool built by one person full-time
• Clean UI, fast startup
• Downsides: feature surface still narrow
• Who: solo devs who find Bruno heavy, Rust ecosystem fans

Bambda

• JavaScript-based API client
• Supports WebSocket, SSE, gRPC
• Emphasizes AI features
• Small user base so far
• Who: new small teams willing to experiment

14. AI integration — Postbot, Insomnia AI

By 2026 almost every tool has AI features. Where is the real value?

What AI does well

1. Generate requests — "get the repo list for an organization from the GitHub API" → request gets created
2. Explain responses — point at a response JSON and explain what each field means
3. Auto-write tests — read the response and generate assertions (status code, schema, ...)
4. OpenAPI design assist — turn a natural-language description into a schema draft
5. Debug errors — given a 401/403/500, list likely causes

Why Postbot stands out

Postman has an enormous context — collections + history + environments. Its AI can produce new requests "in the style of the other requests in your collection." Stand-alone AIs in other tools lack this org-internal context and produce generic outputs.

Why Insomnia AI stands out

Kong Konnect integration — the AI understands the API catalog and policies that Kong knows about. Powerful for orgs already on Konnect.

Limits

• If the natural-language prompt is ambiguous, the AI guesses wrong — humans still correct
• Response explanation is helpful but risks shipping security-sensitive payloads to an external model (enterprises need self-hosted options)
• Auto-generated tests are a fine starting point, but domain logic still needs human input

15. Korea / Japan — Toss, Mercari

Toss (Korea)

Toss is known for taking API design extremely seriously. Public APIs live at docs.tosspayments.com and the internal doc system is recognized for clean design and consistent vocabulary. Internally:

• API design review culture (OpenAPI changes arrive as PRs)
• Bilingual Korean/English docs
• Explicit changelog and deprecation policy
• Auto-generated SDKs in several languages (OpenAPI generator variants)

The Toss tech blog at toss.tech regularly publishes API-design content.

Mercari (Japan)

Mercari is the large Japanese marketplace. Internally they use gRPC extensively and built a custom Protobuf schema governance system. The engineering.mercari.com blog has posts on adopting Buf and the Connect protocol. Their public API surface is small but their internal microservice tooling adoption is fast.

Another Japan example: LINE runs its own internal API tooling ecosystem (LY corp.), and many large Japanese enterprises use SmartBear ReadyAPI extensively.

16. Who should pick what

Final summary.

Solo dev / small side project

• Client: Bruno (git friendly) or Hoppscotch (instant in browser)
• Docs: Scalar (pretty) or framework-default Swagger UI
• gRPC: gRPCurl
• AI: optional (or just use ChatGPT/Claude desktop)

Small engineering team (5-20)

• Client: Bruno + git (PR reviews), Hoppscotch as backup
• Design: Write OpenAPI directly + Spectral lint (commit alongside Bruno)
• Docs: Scalar self-hosted, or Mintlify if going public
• gRPC: Buf + Kreya, or Postman gRPC
• AI: ChatGPT/Claude to assist (in-tool AI is optional)

Large organization / enterprise

• Client: Postman (most polished) or Insomnia (if on Kong)
• Design: Stoplight Studio (PM/designer collaboration) or Apidog
• Docs: ReadMe (if you need external dev dashboards) or Mintlify (modern UX)
• gRPC: Buf BSR + Postman gRPC
• AI: Postbot or Insomnia AI (organization context)
• Compliance: Evaluate self-host options (Hoppscotch, Insomnia Local Vault, Bruno)

API-first company (the product is the API — Stripe/Twilio scale)

• Design: OpenAPI/Protobuf in git as the source of truth
• Client: Bruno internally; for external try-it use Scalar/Redoc
• Docs: Hosted on your own domain (Redocly enterprise, Mintlify enterprise, or custom)
• gRPC: Buf + Connect (browser-compatible)
• Marketplace: Run your own dev portal; expand to RapidAPI later if it helps

Closed (all APIs are internal)

• Client: Bruno + git (the most natural)
• Design: Place OpenAPI next to the code (openapi.yaml file)
• Docs: Scalar self-hosted, or framework default
• gRPC: Buf + Kreya/gRPCurl
• AI: Follow internal LLM policy

Open-source absolutist

• Client: Hoppscotch (self-host) or Bruno
• Docs: Redoc + Spectral + Prism
• gRPC: Buf (Apache 2.0) + gRPCurl
• Marketplace: Run your own dev portal

Closing

Five-year changes, summarized

• Client: Postman monopoly → multi-polar Bruno/Insomnia/Hoppscotch
• Data ownership: cloud default → local/git options matter again
• Docs: Swagger UI monopoly → Scalar/Redoc/Mintlify generation shift
• gRPC: tooling chaos → Buf is the de facto standard
• AI: nice-to-have → default in almost every tool
• Compliance: indifferent → self-host / local mode is now selection criteria

Ten antipatterns

1. Adopting Postman because "big tools are safe" — discovers compliance friction late
2. Standardizing on a SaaS API client without a data ownership policy — gets blocked by security
3. Not committing collections to git — no PR review possible
4. Code without an OpenAPI spec — docs always drift from code
5. Operating without Spectral / Buf breaking — humans discover compat breaks
6. Exposing Swagger UI directly to the public — its dated look hurts brand perception
7. Trusting AI-generated assertions blindly — wrong tests get committed
8. Doing gRPC inside Postman only — falls short when gRPC-native precision is needed
9. Starting frontend without a mock server — sprint stalls waiting for backend
10. Hand-writing docs — they drift from code within a week

Next post

Candidates: OpenAPI 3.1 deep dive — JSON Schema unification and webhooks, Connect protocol vs gRPC vs REST — the 2026 choice, API mocking tools compared — Prism, MSW, WireMock.

"API tooling is not just tooling for code. It is tooling for the agreement between people who build APIs. When the agreement is clean, the tooling is light."

— API Design & Testing Tools 2026, end.

References

• Bruno — Opensource API client
• Bruno GitHub — usebruno/bruno
• Bruno Series A announcement (2024)
• Insomnia — Kong
• Insomnia 8 controversy — GitHub issues
• Postman
• Postman Scratch Pad announcement
• Postbot — AI in Postman
• Hoppscotch
• Hoppscotch GitHub — hoppscotch/hoppscotch
• Stoplight
• SmartBear acquires Stoplight
• Spectral — OpenAPI linter
• Prism — mock server
• Scalar
• Scalar GitHub — scalar/scalar
• Redoc GitHub — Redocly/redoc
• Redocly
• Swagger UI
• Mintlify
• ReadMe.com
• Buf
• Buf Schema Registry
• Buf Connect
• gRPCurl — fullstorydev/grpcurl
• Kreya
• Apidog
• Yaak
• RapidAPI Hub
• Kong Konnect
• TossPayments API Docs
• Toss Tech blog
• Mercari Engineering blog
• OpenAPI Initiative
• JSON Schema