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.
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
It is open source, fast, and available as a standard npm package:
npm i -g @hoppscotch/cli
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:
- Open the collection you currently run in CI.
- Use the collection menu and choose Export.
- Save the exported
.jsonfile. - Open the environments panel.
- 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
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"
}
Create matching variables in the Apidog Staging environment:
base_url
api_token
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
After:
apidog run \
--access-token "$APIDOG_TOKEN" \
-e "Staging"
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"
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
In Apidog, pass the dataset with -d:
apidog run \
--access-token "$APIDOG_TOKEN" \
-e "Staging" \
-d ./data/orders.csv
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
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
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
Use JSON when another tool needs to parse the result:
apidog run \
--access-token "$APIDOG_TOKEN" \
-e "Staging" \
-r json
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,
-dmeans delay in milliseconds. - In Apidog,
-dmeans 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
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)