Home › API Mocking › Hoppscotch

Hoppscotch Review 2026: Browser-First API Testing That Mocks Just Enough

A zero-install API client with real protocol breadth and a self-hostable core — but its mock server is a starter kit, not a simulator.

Engineers who want a fast, self-hostable API client for REST, GraphQL, WebSocket and SSE work, and who only need lightweight canned mock endpoints rather than a full stateful simulator.
8.2
Editor score · 10
License
MIT (Community core)
Deployment
Web app, PWA, desktop build (Tauri), Docker self-host
Protocols
REST, GraphQL, WebSocket, SSE, Socket.IO, MQTT
Mock server
Static responses from saved requests, hosted or self-hosted URL
Automation
hoppscotch-cli for headless collection runs in CI
Interop
Imports Postman, Insomnia, OpenAPI and HAR collections

Overview

Hoppscotch installs by opening a URL. It is a PWA, so the browser caches the app shell and you get an installable client without a 400 MB Electron download. For someone who lives in a terminal and only needs to poke an endpoint, that friction difference is the whole pitch. The first thing you will hit is CORS: turn on the built-in proxy or install the browser extension, otherwise half your requests fail with the same opaque error. Then create a collection, define an environment with variables like baseUrl and token, and you are productive in under five minutes. Self-hosting is a Docker Compose stack with Postgres and Redis, which is more moving parts than a single binary but nothing a backend team cannot handle.

Mocking is where Hoppscotch quietly earns its keep. You define a collection, point it at the mock server, and it returns generated responses you can shape with status codes, payloads, and per-request overrides. Because collections and environments are the same objects you already use for real traffic, flipping a frontend from mocks to staging is a variable swap, not a rewrite. The mock endpoints live next to the request definitions, so the contract and the client never drift into separate tools. If your frontend team is blocked on an API that does not exist yet, this is the shortest path to unblocking them without standing up a stub server yourself.

A concrete workflow: the backend team publishes an OpenAPI spec, you import it, then attach mock responses to the endpoints that are still vaporware. The React app points at the mock base URL in .env.development. When real endpoints land, you change one variable. The part people miss is CI. Hoppscotch ships a CLI that runs a collection headlessly, so the same requests you mocked by hand can assert on every pull request. That closes the loop between mocking, documentation, and regression checking without buying a separate tool. It is a genuinely lean setup for small teams.

The cons are real. OAuth flows are fiddly compared with Postman's polished auth helpers, and scripted pre-request logic is less capable. The plugin and integration ecosystem is thin, so if your workflow depends on hooks into CI vendors or API gateways, you will write glue. Collaboration and shared workspaces live in the cloud or Enterprise self-host tiers, not the free local experience. The CLI is younger than the GUI and occasionally lags on collection features. And browser-first means you are one aggressive tab-discard away from losing an unsaved draft, so export collections to a git repo early.

Versus alternatives: Postman is the kitchen-sink option and charges accordingly; Insomnia has burned trust with licensing pivots; Bruno is excellent if you want offline, git-native, file-per-request simplicity but has a lighter mock story; Thunder Client is convenient only if you already live in VS Code. Pick Hoppscotch when you want a fast, open-source, self-hostable client where mocking is a first-class citizen and your team is comfortable owning a Compose stack. Do not pick it if you need deep scripting, enterprise auth flows out of the box, or a large plugin marketplace. It optimizes for speed and openness, not breadth.

How we scored it

Protocol coverage 9/10
Mock server depth 6/10
Self-hosting and data control 9/10
UX and performance 9/10
Team collaboration and governance 7/10

Pricing

Community Edition (self-hosted)
$0
MIT-licensed core you run yourself. Unlimited seats, all protocols, mock servers, the CLI, and no telemetry you didn't ask for.
Cloud Pro
~$12/user/mo
Hosted workspaces, shared collections and environments, version history, and managed mock server URLs. Billed annually.
Enterprise
Custom
SAML/SSO, audit logs, granular roles, on-prem support contracts, and SLA-backed uptime for hosted deployments.

In practice

bash
# Run the same collection headlessly in CI, mock or real
npm i -g @hoppscotch/cli

hopp test ./collections/payments.json \
  --env ./envs/mock.json \
  --reporter json > results.json

jq 'if (.failures | length) == 0 then "green" else "red" end' results.json

The CLI turns hand-built mock collections into assertions that run on every pull request, which is the difference between a demo and a testing strategy.

Quick verdict

Best-in-class for teams that want a browser-fast, open-source API client with self-hosting as a first-class option rather than an enterprise upsell.

Mocking, environments, and collection runs share one data model, so you are not reconciling a mock tool against a client against a test runner.

Weak spots are auth helpers, scripting depth, and ecosystem breadth. If Postman's advanced features are load-bearing for you, migration will hurt.

Choose it for greenfield projects, internal tooling, and frontend teams blocked on unfinished backends. Skip it if you need heavyweight automation or vendor integrations.

Pricing breakdown

Self-hosted: the core is open source, so the software cost is zero. Your real bill is infrastructure (a small Postgres plus Redis plus the app container) and the engineer-hours to maintain upgrades, backups, and SSO wiring.

Cloud free tier: fine for individuals and evaluation. Expect limits on shared workspaces and history, which is exactly the pressure point for a team of three or more.

Cloud paid seats: billed per user per month with collaboration, shared collections, and longer retention. Costs scale linearly with headcount, so compare against a per-seat Postman quote before assuming it is cheaper.

Enterprise self-host adds SSO/SAML, audit logging, and support. Verify current numbers on their pricing page, since tiers and seat minimums shift, and model the three-year cost including the ops time you absorb when self-hosting.

Verdict

Hoppscotch wins on the things that annoy people daily: it opens in a tab, no account is required, and the Community edition can be self-hosted so your collections and mock URLs never live on someone else's infrastructure. The mock server is the weak link — it hands out static response bodies per saved request and stops there, with no request matching, templating, or state. Use it as your client and as a quick contract stub for frontend kickoff, then graduate to WireMock or Mockoon once behavior matters.

DevKit Central is editor-independent. Some links are affiliate links; we may earn a recurring commission if you subscribe. This never affects our verdicts.

How the field scores

WireMock
8.6
Mockoon
8.6
Postman
8.0
Prism
8.4
Apidog
8.4
MockServer
8.4
Bruno
8.2
Hoppscotch
8.2
Insomnia
8.2
Swagger UI
7.6
JSONPlaceholder
7.6
HTTPie
8.4
SoapUI
7.3
Is Hoppscotch a real Postman replacement?
For day-to-day request building, environments, and collection runs, yes — the muscle memory transfers in an afternoon. Where it falls short is the long tail: heavy scripting APIs, deep test-report tooling, and enterprise governance. If your team lives inside collection-level test suites with rich assertions, you will notice the gaps.
Can I replace WireMock with Hoppscotch's mock server?
Not for anything behavioral. Hoppscotch mocks are effectively saved responses served from a generated base URL. There is no request matcher beyond the path, no response templating, no scenario state, and no fault injection. It is fine for unblocking a frontend on day one; it is not fine for testing retries, timeouts, or error cascades.
Does Hoppscotch route my requests through its servers?
Hosted usage in the browser is subject to CORS, so the app offers a proxy/interceptor path when a target API lacks the right headers. Self-host everything, or use the desktop build, and traffic stays between you and the API you're calling. Read the proxy settings before you point it at production credentials.
Does it work offline?
It is a PWA, so once loaded it keeps working with intermittent connectivity, and collections cached locally survive a dropped connection. The desktop app removes the browser dependency entirely. Sync between devices only happens when you're online.