Hoppscotch
Open-source web-based API client. No install required — just open your browser and start testing APIs.
Overview
Hoppscotch, created in 2019, is an open-source, web-based API client that runs entirely in the browser. Unlike Postman or Insomnia which require a desktop application, Hoppscotch works on any device with a web browser — no installation needed. It supports REST, GraphQL, WebSocket, SSE, Socket.io, and MQTT protocols.
Hoppscotch is particularly popular with developers who want a lightweight, portable API client that does not require admin rights to install. It is also a good choice for teams that want a self-hosted API client for privacy reasons.
What it's used for
Hoppscotch is ideal when:
- No-install API testing: Test APIs from any browser without installing software.
- Lightweight workflows: Quick API checks without launching a heavy desktop app.
- Self-hosted option: Deploy your own instance for team privacy.
- Multiple protocols: REST, GraphQL, WebSocket, SSE, Socket.io, and MQTT in one tool.
Pros & Cons
Pros
- No installation required — runs in any browser
- Supports multiple protocols (REST, GraphQL, WebSocket, etc.)
- Open source with self-hosted option
- Lightweight and fast
- Active community with regular updates
Cons
- Browser-based — some features limited by browser security
- No native desktop app (PWA available)
- Smaller ecosystem than Postman
- Cloud sync requires account
- Some advanced testing features are missing
Platforms & Integrations
Hoppscotch runs in any modern web browser. A PWA version is available. Self-hosted deployment requires Node.js.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Full client, all protocols, community support |
| Hoppscotch Enterprise | Custom | SSO, audit logs, dedicated support, custom deployment |
NZ Context
Hoppscotch is popular among NZ developers who want a quick, install-free API client. It is commonly used for quick API debugging and testing when Postman feels like overkill. For NZ teams with locked-down workstations (common in government and banking), Hoppscotch provides an accessible alternative.
Alternatives
- Postman — More features, better collaboration, desktop app available.
- Insomnia — Desktop app with local storage and GraphQL focus.
- Bruno — Git-native collections with local file storage.
When to choose Hoppscotch
A quick decision guide for NZ teams evaluating API testing options.
| Choose Hoppscotch when… | Choose something else when… | Combine with… |
|---|---|---|
| Your workstation is locked down and you cannot install desktop apps — common in NZ government and banking environments. | Your team needs shared collections with role-based access and audit history — use Postman instead. | Newman or k6 for automated contract runs in your CI pipeline after manual exploration in Hoppscotch. |
| You are doing a quick, one-off smoke test of a third-party API and do not want to pollute your Postman workspace with throwaway requests. | Your collections must live in Git alongside the source code — use Bruno, which stores requests as plain files. | Postman for long-lived, team-shared collections; keep Hoppscotch open in a browser tab for ad-hoc exploration. |
| You are testing WebSocket or SSE endpoints and want a single browser-based tool that handles both alongside REST. | You need a scriptable test runner with assertions, test reports, and CI integration — use Insomnia with its built-in test suite or move to a purpose-built framework like REST-assured. | Wireshark or browser DevTools Network tab to confirm what Hoppscotch is sending at the packet level when debugging tricky auth headers. |
| Your team wants to self-host an API client inside a private VPC so credentials never leave the organisation's network. | Your QA chapter has already standardised on Postman and built extensive collections — switching costs outweigh the benefits. | A password manager like 1Password to inject environment secrets into Hoppscotch environment variables without hardcoding credentials. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
The bottom line: Hoppscotch is not your collection manager — it is your scratch pad. Use it to move fast, figure out an API, and unblock yourself. Once a request is worth keeping, promote it into Postman or Bruno where it can be versioned, shared, and automated.
Interview questions
Questions you are likely to get if you list Hoppscotch on your CV — with what interviewers are really testing for.
What is the difference between Hoppscotch and Postman, and when would you choose one over the other?
What they’re really testing: Whether you understand tool trade-offs or just listed the first API client you touched.
Strong answer covers: Hoppscotch is browser-based and zero-install, Postman has richer collection management and CI integration via Newman; explain that you would use Hoppscotch for quick ad-hoc exploration and promote stable requests into Postman once they are worth keeping; mention NZ locked-down workstation environments (government, banking) where Hoppscotch is often the only viable option.
When would you use Hoppscotch over Bruno for API testing?
What they’re really testing: Whether you know the modern API tooling landscape beyond just Postman and can articulate precise fit-for-purpose reasoning.
Strong answer covers: Bruno stores collections as plain files committed to Git, making it ideal for teams who want requests version-controlled alongside source code; choose Hoppscotch when there is no install option or you need WebSocket and SSE support in one tool; the two are not mutually exclusive — Hoppscotch for exploration, Bruno for persisted collections.
You are joining Revenue NZ as a contractor to test a new REST endpoint on the myIR platform. Your Standard Operating Environment laptop blocks software installs and flags browser extensions. How would you set up your API testing workflow?
What they’re really testing: Whether you can operate effectively in constrained government or enterprise environments without needing admin rights.
Strong answer covers: Open hoppscotch.io directly in Chrome — no install, no extension required; configure environment variables for the base URL and Bearer token so credentials are never hardcoded into individual requests; export the collection as JSON and commit it to the test repository daily so nothing is locked in a cloud account that expires when the contract ends.
Your API requests pass in Hoppscotch but fail when the same collection runs in CI. What would you investigate first?
What they’re really testing: Whether you understand the difference between a browser-based client and a headless CI runner, and can diagnose environment-specific failures systematically.
Strong answer covers: Check that environment variables (base URL, auth tokens) are correctly injected in CI and not relying on values cached in the browser; confirm CORS headers are not the blocker — Hoppscotch can hit CORS issues a headless runner would skip; verify the CI runner has network access to the target environment (especially in NZ government VPCs with strict egress rules); check whether Hoppscotch collections exported to Newman preserve all pre-request scripts and variable references.
How would you structure Hoppscotch usage across a QA team so that exploratory discoveries do not get lost and useful requests eventually make it into the automated suite?
What they’re really testing: Whether you can think at team-process level, not just individual tooling, and whether you understand Hoppscotch’s role as a scratch pad versus a collection manager.
Strong answer covers: Define a clear promotion workflow — Hoppscotch is the scratch pad for exploration, Postman or Bruno is the source of truth for stable collections; establish a naming convention and weekly review to promote any request used more than once; use Hoppscotch environment exports committed to a shared repo folder as a lightweight handoff mechanism; avoid letting Hoppscotch become the de-facto collection manager by accident, which leads to knowledge silos in individual browser accounts.