DEV Community

Cover image for How to Migrate From the Hoppscotch CLI to Apidog CLI
Hassann
Hassann

Posted on • Originally published at apidog.com

How to Migrate From the Hoppscotch CLI to Apidog CLI

The Hoppscotch CLI is a clean, free way to run API collections from a terminal or CI pipeline. hopp test reads a collection file, executes each request, runs pre-request and test scripts, and exits with a non-zero status when an assertion fails. For many teams, that is enough.

Try Apidog today

But an API runner is only one part of the workflow. Once your team is designing APIs in one tool, mocking in another, publishing docs somewhere else, and running tests separately, you lose a shared source of truth. That is when migrating from Hoppscotch CLI to Apidog CLI can make sense. Apidog combines API design, debugging, mocking, documentation, and testing in one platform, while its CLI runs tests in CI.

When you should and shouldn’t migrate

Stay on Hoppscotch CLI if your only requirement is:

hopp test collection.json
Enter fullscreen mode Exit fullscreen mode

It is open source, fast, and available as a standard npm package:

npm i -g @hoppscotch/cli
Enter fullscreen mode Exit fullscreen mode

Consider migrating when these problems start slowing you down:

  • API design, mocks, docs, and tests live in separate tools.
  • Test runs, mock servers, and published docs need to share one project definition.
  • You need richer reports, such as HTML for humans and JSON for automation.
  • You want endpoints, schemas, environments, and branches managed from one API project.

The reason to migrate is not just the CLI. It is the shared platform around the CLI.

Step 1: Export your Hoppscotch collection and environment

Hoppscotch stores collections and environments as JSON, so migration starts with exports.

In Hoppscotch:

  1. Open the collection you currently run in CI.
  2. Use the collection menu and choose Export.
  3. Save the exported .json file.
  4. Open the environments panel.
  5. Export the environment used by your CLI job.

If your pipeline already runs against local files, you probably have both files already:

npm i -g @hoppscotch/cli

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

Keep both files:

  • checkout-api.json — your collection
  • staging.json — your environment variables

Also check your Node.js version. Current Hoppscotch CLI versions require Node.js v22 or newer. Teams pinned to Node 20 need Hoppscotch CLI v0.26.0. Moving to Apidog CLI can remove that constraint if it is blocking your pipeline.

Step 2: Import the collection into Apidog

Create a project in Apidog, or open an existing one.

Then import your Hoppscotch export into the project. Apidog supports common collection formats and OpenAPI, so you can bring the collection into the same workspace where you manage API definitions.

If your API also has an OpenAPI spec, import that too. Apidog validates the spec during import, which helps catch structural issues before they affect test runs.

Next, recreate your Hoppscotch environment as an Apidog environment.

For example, if staging.json contains:

{
  "base_url": "https://api.example.com",
  "api_token": "example-token"
}
Enter fullscreen mode Exit fullscreen mode

Create matching variables in the Apidog Staging environment:

base_url
api_token
Enter fullscreen mode Exit fullscreen mode

Keep variable names identical where possible. That reduces changes to request URLs, headers, and test scripts.

After import, your endpoints are no longer only runnable requests. They can also be used for schemas, mock servers, and published documentation from the same source.

Useful setup references:

Step 3: Map hopp test to apidog run

The CLI model is similar: run requests, execute scripts, evaluate assertions, and fail the process when tests fail.

Before:

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

After:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging"
Enter fullscreen mode Exit fullscreen mode

The important CI behavior stays the same: failed assertions produce a non-zero exit code.

That means your pipeline can continue to rely on shell exit status:

apidog run --access-token "$APIDOG_TOKEN" -e "Staging"
Enter fullscreen mode Exit fullscreen mode

If tests fail, the job fails.

Authentication changes slightly. Hoppscotch can use --token for cloud or self-hosted collections. Apidog uses login or an access token so the CLI can access resources in your Apidog project.

See the Apidog CLI authentication walkthrough for the available auth options.

Step 4: Convert data-driven runs

Hoppscotch supports iteration data:

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json \
  --iteration-count 50 \
  --iteration-data ./data/orders.csv
Enter fullscreen mode Exit fullscreen mode

In Apidog, pass the dataset with -d:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging" \
  -d ./data/orders.csv
Enter fullscreen mode Exit fullscreen mode

Apidog supports CSV and JSON datasets. If your CSV uses a header row, those column names become variables you can reference in requests and assertions.

Example orders.csv:

order_id,expected_status
1001,paid
1002,pending
1003,cancelled
Enter fullscreen mode Exit fullscreen mode

Your requests and assertions can use the same variable-driven pattern after migration, as long as the variable names are preserved.

For details, see the Apidog CLI data-driven testing guide.

Step 5: Convert your reporters

Hoppscotch can output JUnit XML:

hopp test ./collections/checkout-api.json \
  -e ./environments/staging.json \
  --reporter-junit ./reports/results.xml
Enter fullscreen mode Exit fullscreen mode

Apidog supports CLI, HTML, and JSON reports, and can upload reports for cloud run history.

Example HTML report with upload:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging" \
  -r html \
  --upload-report
Enter fullscreen mode Exit fullscreen mode

Use JSON when another tool needs to parse the result:

apidog run \
  --access-token "$APIDOG_TOKEN" \
  -e "Staging" \
  -r json
Enter fullscreen mode Exit fullscreen mode

If your CI dashboard specifically depends on JUnit XML, account for that during migration. Apidog focuses on CLI, HTML, JSON, and cloud reports rather than a JUnit-specific flag.

For report options, see the Apidog CLI test reports guide.

Before and after: command mapping

Task Hoppscotch CLI Apidog CLI
Install npm i -g @hoppscotch/cli Per the installation guide
Run a collection hopp test collection.json apidog run
Select environment -e env.json -e "Staging"
Auth token --token <pat> login / --access-token
Self-hosted / cloud target --server <url> project + access token
Data-driven inputs --iteration-data orders.csv -d orders.csv
Repeat runs --iteration-count 50 iteration dataset
Add delay between requests -d <ms> per-scenario settings
JUnit report --reporter-junit results.xml -r json or CLI / HTML
Cloud run history not built in --upload-report

Watch the -d flag during migration:

  • In Hoppscotch, -d means delay in milliseconds.
  • In Apidog, -d means dataset for data-driven runs.

That flag collision is an easy migration mistake.

Step 6: Wire it into GitHub Actions

Add the Apidog job beside your existing Hoppscotch job first. Confirm it passes for a few runs, then remove the old job.

name: API tests

on: [push, pull_request]

jobs:
  apidog-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run API tests
        env:
          APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}
        run: |
          apidog run \
            --access-token "$APIDOG_TOKEN" \
            -e "Staging" \
            -d ./data/orders.csv \
            -r html \
            --upload-report
Enter fullscreen mode Exit fullscreen mode

Store the access token as a repository secret. Do not hard-code it in the workflow file.

Because apidog run exits non-zero on failed assertions, GitHub Actions fails the job when your API tests fail. That preserves the CI behavior your team already relies on.

More CI references:

Once the Apidog job is stable, delete the Hoppscotch step and remove its npm install from the pipeline.

A fair word on Hoppscotch

Hoppscotch CLI is still a strong option. It is fast, free, open source, and self-hostable. If you only need a lightweight collection runner, staying with Hoppscotch is reasonable.

The reason to switch is scope. When API design, mocks, docs, and tests need to share one definition, an integrated platform can reduce manual sync work.

For more comparison context, see:

Top comments (0)