Insomnia
A streamlined, lightweight API client with excellent GraphQL support and local storage for privacy-conscious teams.
Overview
Insomnia, created by Kong in 2015, is an open-source API client designed for developers who find Postman too heavy or cluttered. It focuses on speed, simplicity, and developer experience. Insomnia stores collections locally by default (no cloud required), making it popular with privacy-conscious teams and government organisations.
In 2026, Insomnia is particularly strong for GraphQL workflows, offering schema introspection, query autocomplete, and variable management that rivals or exceeds Postman's GraphQL support.
What it's used for
Insomnia is ideal when:
- Lightweight API client needed: Fast startup, minimal UI chrome, no bloat.
- GraphQL is primary: Superior GraphQL IDE experience with schema-driven autocomplete.
- Privacy matters: Local storage by default — no data leaves your machine unless you choose to sync.
- Open source preferred: Fully open-source core with transparent development.
Pros & Cons
Pros
- Fast and lightweight compared to Postman
- Best-in-class GraphQL support
- Local storage by default — privacy-first
- Clean, distraction-free UI
- Open source with active community
Cons
- Smaller ecosystem than Postman (fewer integrations, plugins)
- Collaboration features are weaker than Postman Teams
- No native CI runner equivalent to Newman
- Less suitable for non-technical testers
- Kong ownership has caused some community concern about future direction
Platforms & Integrations
Insomnia runs on Windows, macOS, and Linux. It supports REST, GraphQL, gRPC, and WebSocket APIs.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | All core features, local storage, unlimited requests |
| Insomnia Plus | $5/user/mo | Cloud sync, team collaboration, unlimited projects |
| Enterprise | Custom | SSO, audit logs, dedicated support, on-premise sync |
NZ Context
Insomnia is popular among NZ developers who prefer lightweight tools. It is particularly common in NZ government agencies where data residency and privacy are paramount. For GraphQL-heavy NZ startups (like Figured in agtech), Insomnia is often the preferred API client.
Alternatives
- Postman — More features, better collaboration, larger ecosystem.
- Hoppscotch — Web-based, open-source alternative. No install required.
- Bruno — Git-friendly API client with local collection storage.
When to choose Insomnia
A quick decision guide for NZ teams evaluating api testing options.
| Choose Insomnia when… | Choose something else when… | Combine with… |
|---|---|---|
| Your API layer is GraphQL-heavy and you need schema introspection, autocomplete, and variable management in one place. | Your team runs automated regression suites in CI — Postman’s Newman runner has a far larger ecosystem and documented integrations with GitHub Actions and Bamboo. | Playwright or k6 for load and end-to-end coverage that Insomnia can’t run headlessly. |
| Data sovereignty is a hard requirement — Insomnia stores collections on-device by default, with no phone-home unless you opt into cloud sync. | Your non-technical BAs or product owners need to send requests and interpret responses — Postman’s guided UI and documentation features are more accessible to non-developers. | Bruno for Git-tracked collection versioning alongside Insomnia for exploratory testing — both local-first, complementary workflows. |
| You are a solo developer or small team and want a fast, uncluttered client without paying for collaboration seats. | You need shared workspaces, role-based access, and audit logs across a large QA team — Postman Teams or API management platforms like Kong Gateway handle this better. | Swagger UI or Redoc for publishing the API contract to stakeholders while using Insomnia internally for testing. |
| Your stack includes gRPC or WebSocket endpoints that many REST-only tools handle poorly. | Your organisation is standardising on a single toolchain with a vendor support agreement — Insomnia’s Kong ownership and evolving roadmap introduce uncertainty compared to Postman’s enterprise licensing. | Wireshark or Charles Proxy for deep traffic inspection when Insomnia’s response view is not enough. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
The bottom line: Insomnia earns its place as a specialist tool — reach for it when GraphQL, gRPC, or data-sovereignty requirements make Postman the wrong default, not as a wholesale replacement for teams already invested in the Postman ecosystem.
Interview questions
Questions you are likely to get if you list Insomnia on your CV — with what interviewers are really testing for.
What is the difference between Insomnia and Postman, and when would you choose one over the other?
What they’re really testing: Whether you understand the trade-offs between tools or just list whatever you’ve used without critical evaluation.
Strong answer covers: Insomnia’s local-first storage vs Postman’s cloud-default model; Insomnia’s superior GraphQL IDE (schema introspection, autocomplete); Postman’s stronger CI story via Newman and larger integration ecosystem; mention a concrete NZ context such as government agencies preferring Insomnia because data residency rules make Postman’s cloud sync a compliance risk.
When would you use Insomnia over Bruno or Hoppscotch for API testing?
What they’re really testing: Whether your tool knowledge goes beyond the two big names and whether you can articulate genuine capability differences rather than vague preferences.
Strong answer covers: Insomnia for native gRPC and WebSocket support that Bruno and Hoppscotch lack; Bruno for Git-first workflows where collections are committed as plain-text files; Hoppscotch when there is no install access (web-based, zero footprint); note that for a NZ team with mixed REST/GraphQL/gRPC services, Insomnia is often the only single-client option that handles all three protocols cleanly.
You’re joining the QA team at CloudBooks and they use Postman for everything, but the payroll API is being migrated to GraphQL. How would you approach tooling?
What they’re really testing: Pragmatism — can you introduce a better-fit tool without triggering a disruptive full migration, and do you understand the cost of tool switching?
Strong answer covers: Keep Postman for existing REST regression and Newman CI runs; introduce Insomnia only for the GraphQL workflow where schema introspection eliminates typo-driven failures when the schema evolves; run both tools in parallel rather than forcing migration; quantify the switching cost (re-writing collections, retraining the team) against the specific GraphQL pain being solved.
Your Insomnia requests pass locally but the same endpoints return 401s in CI. How do you debug this?
What they’re really testing: Systematic debugging instinct and understanding of environment variable management, not just tool familiarity.
Strong answer covers: Check that environment variables (base URLs, auth tokens) are correctly configured in the CI environment and not leaking from a local Insomnia environment file; verify token expiry — short-lived JWTs may be valid locally but expire by the time CI runs; confirm Insomnia’s export format preserves the auth header or bearer token configuration; note that because Insomnia lacks a native CLI runner like Newman, CI usually means exporting to a format and running via a wrapper or switching to a different execution layer.
How would you structure and version-control an Insomnia collection for a team of six QA engineers working across multiple services at a company like TechServNZ?
What they’re really testing: Whether you treat test assets as first-class code artefacts that need versioning and review, not as individual scratch files.
Strong answer covers: Use Insomnia’s built-in Git Sync to commit collections as JSON files into the same repository as the service code; enforce PR reviews on collection changes so broken requests are caught before merging; use Insomnia environments to separate dev/staging/production base URLs without duplicating requests; at TechServNZ scale consider whether a shared Kong Gateway API portal gives a better single source of truth for the API contract, with Insomnia used only for exploratory and ad-hoc testing on top of that.