Skip to main content

How to Migrate from Postman to Hoppscotch in 2026

·OSSAlt Team
postmanhoppscotchmigrationapi-testingguide
Share:

How to Migrate from Postman to Hoppscotch in 2026

Why Switch from Postman?

Postman was the dominant API testing tool for years, but the 2023 changes broke a lot of workflows: the local storage feature was deprecated (all data now requires a Postman account), and the free tier limits collaboration to 3 users. The Professional plan costs $14/user/month — $168/user/year. For a 10-person engineering team, that's $1,680/year for an API client.

Hoppscotch is the open source alternative. It runs in the browser (no Electron app), supports every protocol Postman supports plus several it doesn't (WebSocket, SSE, MQTT, gRPC), and self-hosted versions allow unlimited users with no per-seat licensing.

This guide covers exporting from Postman, deploying self-hosted Hoppscotch, importing your collections, setting up team workspaces, and adjusting to the key differences between the two tools.


Step 1: Export Everything from Postman

Before switching, export all data from Postman. You'll need:

  • Collections (API request groups)
  • Environments (variable sets for different stages)
  • Global variables

Export a collection:

  1. In Postman, right-click on a collection → Export
  2. Select Collection v2.1 format (Hoppscotch imports v2.1)
  3. Save the JSON file

Export all collections at once (API):

# Get all collections via Postman API
POSTMAN_API_KEY="your-postman-api-key"  # From Postman Settings → API Keys

# List all collections
curl -H "X-API-Key: $POSTMAN_API_KEY" \
  "https://api.getpostman.com/collections" \
  > collections-list.json

# Export each collection by ID
jq -r '.collections[].uid' collections-list.json | while read uid; do
  curl -H "X-API-Key: $POSTMAN_API_KEY" \
    "https://api.getpostman.com/collections/$uid" \
    > "collection-$uid.json"
done

Export environments:

  1. Click the Environments tab in the left sidebar
  2. For each environment: click Export
  3. Save each environment JSON file

Step 2: Set Up Hoppscotch

Option A: Use hoppscotch.io (instant, no setup)

Go to hoppscotch.io — sign in with GitHub, Google, or email. Free tier allows unlimited requests with no collaboration limits for small teams.

Option B: Self-host (recommended for teams)

Self-hosted Hoppscotch requires a PostgreSQL database and an SMTP server for authentication emails:

# docker-compose.yml for self-hosted Hoppscotch
version: "3"

services:
  hoppscotch-backend:
    image: hoppscotch/hoppscotch-backend:latest
    restart: unless-stopped
    environment:
      - DATABASE_URL=postgresql://hoppscotch:password@postgres:5432/hoppscotch
      - JWT_SECRET=your-jwt-secret-min-32-chars
      - TOKEN_SALT_COMPLEXITY=10
      - MAGIC_LINK_TOKEN_VALIDITY=3
      - REFRESH_TOKEN_VALIDITY=604800000
      - ACCESS_TOKEN_VALIDITY=86400000
      # SMTP for magic link login emails
      - MAILER_SMTP_URL=smtps://user:pass@smtp.yourdomain.com:465
      - MAILER_ADDRESS_FROM=Hoppscotch <noreply@yourdomain.com>
      # CORS
      - WHITELISTED_ORIGINS=https://api.yourdomain.com,https://app.yourdomain.com
      - VITE_ALLOWED_AUTH_PROVIDERS=EMAIL,GITHUB,GOOGLE
      # OAuth (optional)
      # - GOOGLE_CLIENT_ID=your-google-client-id
      # - GOOGLE_CLIENT_SECRET=your-google-client-secret
      # - GITHUB_CLIENT_ID=your-github-client-id
      # - GITHUB_CLIENT_SECRET=your-github-client-secret
    depends_on:
      - postgres

  hoppscotch-app:
    image: hoppscotch/hoppscotch-app:latest
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - VITE_BASE_URL=https://app.yourdomain.com
      - VITE_SHORTCODE_BASE_URL=https://app.yourdomain.com
      - VITE_BACKEND_GQL_URL=https://api.yourdomain.com/graphql
      - VITE_BACKEND_WS_URL=wss://api.yourdomain.com/graphql
      - VITE_BACKEND_API_URL=https://api.yourdomain.com/v1

  hoppscotch-admin:
    image: hoppscotch/hoppscotch-admin:latest
    restart: unless-stopped
    ports:
      - "3100:8080"
    environment:
      - VITE_BASE_URL=https://app.yourdomain.com
      - VITE_BACKEND_GQL_URL=https://api.yourdomain.com/graphql
      - VITE_BACKEND_API_URL=https://api.yourdomain.com/v1

  postgres:
    image: postgres:15-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: hoppscotch
      POSTGRES_USER: hoppscotch
      POSTGRES_PASSWORD: password
    volumes:
      - hoppscotch_db:/var/lib/postgresql/data

volumes:
  hoppscotch_db:
# Caddy reverse proxy
app.yourdomain.com {
    reverse_proxy localhost:3000
}

api.yourdomain.com {
    reverse_proxy hoppscotch-backend:3170
}
docker compose up -d
# Run database migrations
docker compose exec hoppscotch-backend pnpx prisma migrate deploy

Step 3: Import Collections

  1. Open Hoppscotch → Collections panel (left sidebar)
  2. Click Import/ExportImport from Postman
  3. Upload the collection JSON file (v2.1 format)
  4. Collections import with request folders, headers, body, and parameters

Importing multiple collections:

Repeat for each collection file. Hoppscotch imports them as separate top-level collections, mirroring the Postman structure.

What imports successfully:

  • Request name, URL, method
  • Headers (static values)
  • URL parameters (query strings)
  • Request body (JSON, form data, raw text)
  • Folder hierarchy within the collection
  • Collection-level variables (as environment variables)

What doesn't import:

  • Pre-request scripts (JavaScript)
  • Test scripts (assertions)
  • Dynamic variable generation ({{$randomInt}})
  • Mock servers

Step 4: Set Up Environments

Postman environments become Hoppscotch environments. The key syntax difference: Postman uses {{variableName}} and Hoppscotch uses <<variableName>>.

Create environments in Hoppscotch:

  1. Click Environments in the bottom panel
  2. + New Environment
  3. Add variables with the same names as your Postman environment
# Postman environment variables
baseUrl = https://api.example.com
apiKey = sk_test_xxx
userId = 12345

# Same variables in Hoppscotch
baseUrl = https://api.example.com
apiKey = sk_test_xxx
userId = 12345

Update request URLs after import:

Postman syntax: {{baseUrl}}/users/{{userId}} Hoppscotch syntax: <<baseUrl>>/users/<<userId>>

After importing a collection, you'll need to find/replace all {{ with << and }} with >> in your request URLs and headers. There's no automated migration for this — it requires a manual pass through each request.

Tip: Use the browser's find-in-page (Ctrl+F) in Hoppscotch to spot any remaining {{ patterns in your requests.


Step 5: Explore Protocol Support

One of Hoppscotch's genuine advantages over Postman is built-in support for protocols beyond REST:

REST API requests: Same as Postman — GET, POST, PUT, PATCH, DELETE with full header and body control.

GraphQL:

  1. Click GraphQL in the top navigation
  2. Enter your GraphQL endpoint URL
  3. Hoppscotch automatically introspects the schema
  4. Use the schema explorer to browse types and build queries
# Write your query in the editor:
query GetUser($id: ID!) {
  user(id: $id) {
    name
    email
    createdAt
  }
}

WebSocket:

  1. Click Realtime → WebSocket
  2. Enter your WebSocket URL: wss://api.example.com/ws
  3. Connect, then send and receive messages in the interface
  4. Message history shows the full bidirectional conversation

Server-Sent Events (SSE):

  1. Click Realtime → SSE
  2. Enter the SSE endpoint URL
  3. Hoppscotch connects and displays incoming events in real-time
  4. Useful for testing streaming API responses

MQTT:

  1. Click Realtime → MQTT
  2. Enter broker URL: mqtt://broker.example.com:1883
  3. Subscribe to topics and publish messages
  4. Event log shows subscribed messages

gRPC (protobuf):

  1. Click Realtime → gRPC
  2. Upload your .proto file
  3. Select service and method
  4. Fill in request fields and invoke

Step 6: Team Workspaces (Self-Hosted)

On self-hosted Hoppscotch, team workspaces allow shared collections with granular permissions:

  1. Click WorkspacesNew Workspace
  2. Name it (e.g., "Backend API", "Mobile API")
  3. Invite team members: Workspace Settings → Members → Invite
  4. Set roles: Owner (full control), Editor (edit collections), Viewer (read only)

All workspace members see the shared collections in real-time. Changes sync across all connected browsers immediately.

Moving imported collections to a workspace:

  1. Right-click collection → Move to Workspace
  2. Select the target workspace
  3. Collection is now shared with all workspace members

Key Differences: Postman vs Hoppscotch

FeaturePostmanHoppscotch
InterfaceDesktop app (Electron)Web (PWA)
Variable syntax{{variable}}<<variable>>
Pre-request scripts✅ JavaScriptLimited (environment variables)
Test assertions✅ JavaScript
Mock servers
API monitoring
GraphQL✅ With schema explorer
WebSocket✅ Built-in
SSEPlugin✅ Built-in
MQTTPlugin✅ Built-in
gRPC✅ (beta)✅ Built-in
CLI runnerNewmanHoppscotch CLI
Offline use✅ DesktopPWA (limited)
Team collab3 users (free)Unlimited (self-hosted)

Step 7: Hoppscotch CLI for CI/CD

Hoppscotch has a CLI runner (hopp) for running collections in CI/CD pipelines — similar to Postman's Newman:

# Install
npm install -g @hoppscotch/cli

# Run a collection
hopp test collection.json \
  --env production.json \
  --reporter default

# The collection.json is a Hoppscotch export format (not Postman v2.1)
# Export from Hoppscotch UI: Collections → Export → Hoppscotch JSON

In GitHub Actions:

# .github/workflows/api-tests.yml
name: API Tests

on:
  pull_request:
    branches: [main]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g @hoppscotch/cli
      - run: |
          hopp test api-tests/collection.json \
            --env api-tests/env-staging.json \
            --reporter default

Cost Comparison

PlanPostmanHoppscotch CloudHoppscotch Self-Hosted
Free3 usersUnlimitedUnlimited
Paid$14/user/month$9/user/month$0 (VPS cost only)
10 users$1,680/year$1,080/year$60–120/year
CollectionsCloud only (free tier)Cloud + exportUnlimited
OfflineDesktop appNoNo

Why Postman's Data Model Changed and What It Means for Your Team

Before Postman's 2023 changes, API collections lived in a local SQLite database on your computer. The application was Electron-based, collections were files on disk, and the entire workflow worked without a network connection or account. This was a feature, not a limitation: security-conscious teams could keep API collections containing internal endpoint documentation and authentication flows entirely off-cloud infrastructure.

The 2023 shift to cloud-only data storage fundamentally changed Postman's security posture. Collections are now synced to Postman's servers, associated with your account, and subject to Postman's data retention and access policies. For teams working on internal APIs with sensitive authentication patterns, this represents a real exposure surface that did not exist before.

Hoppscotch's self-hosted option restores the original data residency model: your API collections, environments, and authentication details live on your server, subject to your security controls. For teams in regulated industries or with strict data governance requirements, this is the primary reason to migrate rather than the cost.

The browser-based architecture (PWA rather than Electron) has a different set of trade-offs. Hoppscotch works on any device with a browser, requires no installation, and gets updates automatically. The limitation is that browser APIs have stricter networking policies — certain types of CORS-restricted requests or requests to localhost that Postman's Electron app handles transparently require the Hoppscotch desktop agent. The agent is a small lightweight process that proxies requests from the browser and eliminates these networking constraints.

Building a Collaborative API Testing Workflow

The team workspace feature in self-hosted Hoppscotch enables a workflow pattern that is difficult to replicate in Postman without paying for team accounts: a single source of truth for API collections that all engineers access, edit, and maintain collaboratively.

The effective pattern is to organize workspaces by API service or team boundary rather than by individual engineers. A "Backend API" workspace contains all the service's endpoints. A "Third-Party Integrations" workspace contains collections for external APIs your application calls. Engineers join workspaces they need, with appropriate permission levels.

Collections in shared workspaces are updated in real-time as members edit them — no export-import cycle to keep collections synchronized across team members. When a backend engineer adds a new endpoint, frontend engineers see it appear in their Hoppscotch collection immediately.

This workflow eliminates one of the most persistent friction points in API development: keeping documentation (in the form of API collections) synchronized with implementation. When the collection is the working test environment that engineers use daily, it stays accurate by default.

For teams that want to go further and test API collections as part of CI/CD pipelines, the Hoppscotch CLI runner integrates with GitHub Actions, GitLab CI, and similar systems. Exporting a collection from Hoppscotch, committing it to your repository, and running it in CI on each PR gives you automated API contract testing without additional infrastructure. The how-to-self-host-hoppscotch guide covers the full deployment setup including the CLI configuration for CI/CD workflows.

For teams comparing Hoppscotch against Bruno (another Postman alternative with a distinctly different file-based storage model), the Postman alternatives comparison covers the tradeoffs between the two approaches.

Maintaining API Collections as Living Documentation

The most valuable API collection is one that stays synchronized with the actual API as the codebase evolves. This requires treating collection maintenance as part of the development workflow, not as a separate documentation task.

Collection-as-contract for API development. When building new API endpoints, write the Hoppscotch collection entry before the implementation — defining the request schema, expected response, and edge case test cases first. This collection-first approach ensures that the API client and API server agree on the interface before either is built. The collection becomes the specification that frontend and backend engineers reference during implementation. After implementation, run the collection against the actual endpoint to verify the contract is met.

Environment variable management for multi-stage APIs. Hoppscotch's environment variables allow you to maintain a single collection that works across development, staging, and production environments. Define variables for base URL, API keys, and test user credentials in separate environments. Switch environments to run the same collection against different deployment targets. This makes it trivial to verify that a new API endpoint works in development before promoting to staging — run the same collection, switch the environment, observe the same test results against the new target.

Keeping collections synchronized with OpenAPI specs. If your API is documented with OpenAPI/Swagger specifications, Hoppscotch can import OpenAPI specs to generate initial collections. As the spec evolves (new endpoints added, parameters changed), re-importing the spec updates the collection. This import-merge workflow keeps your Hoppscotch collection synchronized with the canonical spec without manual collection editing. Teams using tools like Swagger UI or Stoplight alongside Hoppscotch benefit from having both a browseable spec and a runnable collection generated from the same source of truth.

Regression testing with the CLI. The Hoppscotch CLI allows running collections in headless mode — no browser required. This is the mechanism for API regression testing in CI/CD: before merging a PR that changes backend logic, run the API collection against a test environment and verify all requests return expected responses. Collections with assertion scripts (Hoppscotch supports a JavaScript assertion API similar to Postman's test scripts) can verify response structure, status codes, and specific field values. A collection with comprehensive assertions becomes a regression test suite that catches API breaking changes before they reach production.

For the broader developer tooling landscape including API clients, documentation tools, and testing frameworks, see best open source developer tools 2026.


Related: Best Open Source Developer Tools 2026 · Hoppscotch vs Bruno: Which API Client? · How to Self-Host IT-Tools

See open source alternatives to Postman on OSSAlt.

The SaaS-to-Self-Hosted Migration Guide (Free PDF)

Step-by-step: infrastructure setup, data migration, backups, and security for 15+ common SaaS replacements. Used by 300+ developers.

Join 300+ self-hosters. Unsubscribe in one click.