Moving From Keploy to Apidog CLI

If your team started with Keploy, you probably liked the workflow: run your app, hit endpoints, and get tests without manually writing assertions or stubbing dependencies. Keploy captures real traffic at the network layer and replays it.

Try Apidog today

Moving from Keploy usually means your testing needs changed. Captured tests are useful for regression checks against real behavior, but they can be harder to read, review, and maintain as a team. At some point, you may want tests that are explicit in pull requests, test data you control, environments you can switch with a flag, and mock servers you design instead of mocks derived from recordings.

Two different paradigms, honestly compared

Keploy and Apidog both help with API testing, but they solve the problem differently.

Keploy is an open-source platform for creating isolated test sandboxes. Its key feature is record and replay: using eBPF at the network layer, it captures real API calls and dependencies such as database queries, downstream services, and streaming events without SDKs or code changes. From that captured traffic, it auto-generates test cases and mocks. Keploy can also generate tests from an OpenAPI spec, Postman collection, cURL command, or live endpoint. Because capture happens at the eBPF layer, it is language-agnostic but depends on Linux and elevated privileges. You can read the source on GitHub.

Apidog is an all-in-one API platform for design, debugging, mocking, documentation, and testing. The Apidog CLI, apidog run, executes test scenarios and collections from your terminal or CI/CD pipeline. It supports data-driven testing, environment switching, multiple report formats, and cloud reports. Apidog also provides AI test-case generation, but it works from your API schema and endpoints inside the app, not by recording production traffic.

The important difference: Apidog does not capture live traffic via eBPF, and it does not auto-generate tests by recording production calls plus dependency mocks. That is Keploy’s strength. If runtime capture is central to your workflow, keep Keploy for that job. What you gain with Apidog is explicit, reviewable, cross-team API tests and a platform that covers the whole API lifecycle.

Keploy approach	Apidog approach
keploy record captures real traffic via eBPF	Import your API surface as OpenAPI, Postman, or cURL
Tests auto-generated from captured calls	AI test-case generation from the spec, plus scenarios you author
keploy test --delay 10 replays recordings	apidog run executes authored scenarios in CI
Dependency mocks captured from real DB/network traffic	Mock servers you design and control
Test data baked into the recording	Data-driven testing via -d using CSV or JSON files
Implicit environment from the recorded run	Explicit environments switched with -e
Linux/eBPF, elevated privileges	Runs anywhere the CLI runs, including standard CI runners

Use this table as a migration map. Each Keploy capability becomes a deliberate authoring step in Apidog. You are moving from “the tool inferred behavior from traffic” to “the team defines what correct behavior looks like.”

Step 1: Capture your API surface as a spec

Keploy starts from a running app. Apidog starts from a structured API description.

Your first task is to produce something importable:

• An OpenAPI document
• A Postman collection
• A set of cURL commands

If your service already publishes OpenAPI, use that. If not, generate it from your framework, export your Postman collection, or collect the cURL commands your team already uses for manual testing.

If you have Keploy recordings, use them as an endpoint checklist. They show which endpoints are actually called and with what payloads. You will not import the recordings directly into Apidog, but they can help ensure your spec covers the same API surface.

Step 2: Import into Apidog

Download Apidog, create a project, and import your OpenAPI file, Postman collection, or cURL commands.

Apidog uses the import to populate:

• Endpoints
• Request schemas
• Parameters
• Response models
• Example payloads

You now have a structured API definition that your team can edit, version, and share.

Those imported endpoints are not only test fixtures. They become live documentation, debuggable requests, mock server definitions, and the basis for automated tests.

For a full CLI setup walkthrough, see the Apidog CLI complete guide.

Step 3: Generate a starting test suite, then author real scenarios

This is where you recover some of the speed you liked about Keploy.

Apidog’s AI test-case generation reads your imported schema and endpoints, then drafts test cases such as:

• Valid request cases
• Missing required fields
• Invalid parameter values
• Boundary values
• Common error responses

If you want to compare this workflow with other tools, see the overview of the best AI test-case generators.

Treat AI-generated tests as a draft. Review them, remove irrelevant cases, and tighten assertions.

Also note the limitation: Apidog generates from your spec, not from runtime production behavior. It will not automatically know about quirks that only appear in real traffic. That is the gap Keploy’s capture workflow fills.

After generation, author the scenarios that matter most.

For example, an end-to-end user flow might look like this:

1. Create a user
2. Log in
3. Extract the returned token
4. Fetch the user profile
5. Update the profile
6. Delete the user

In Apidog, this becomes an explicit scenario where each request can pass values to the next step. You can assert on status codes, response fields, headers, and extracted variables.

This is more work than recording traffic, but it produces tests that are easier to review and maintain. For guidance on combining AI output with manual authoring, see how to write test cases with AI assistance.

Step 4: Set environments and data-driven inputs

A Keploy recording captures one run with one set of values. Authored tests should run against multiple environments and datasets.

In Apidog, define environments such as:

• local
• staging
• production

Each environment can have its own:

• Base URL
• Auth token
• API keys
• Variables
• Headers

At run time, choose the environment with -e.

For data-driven testing, attach a CSV or JSON file and pass it with -d. Apidog runs the scenario once per row or dataset.

Example:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -i 123456 \
  -e "staging" \
  -d ./test-data/login-cases.csv

Example CSV:

email,password,expectedStatus
[e-mail],correct-password,200
[e-mail],wrong-password,401
[e-mail],correct-password,403

This gives you test data that can be reviewed in pull requests and extended as new edge cases appear.

For file formats and variable binding, see the data-driven testing guide.

Step 5: Run in CI with apidog run

The command that replaces keploy test in your pipeline is apidog run.

It executes your authored scenarios, applies the selected environment and data file, and emits reports.

Example:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -i 123456 \
  -e "staging" \
  -r html,cli \
  --upload-report

A typical CI job does three things:

1. Install the Apidog CLI
2. Pass the access token and scenario ID
3. Fail the build if apidog run exits with a non-zero status

For implementation details, see:

• CI/CD pipeline guide
• GitHub Actions walkthrough
• test reports guide

Step 6: Build mock servers you control

Keploy creates mocks by capturing dependency traffic during recording.

Apidog takes a different approach: you design the mock behavior from your API schema.

After importing your API definition, you can generate mock servers that return example responses based on field types and rules you configure. You control:

• Response payloads
• Status codes
• Error cases
• Latency
• Example data
• Contract behavior

The tradeoff is clear:

• Captured mocks reflect what dependencies actually did during a real run.
• Designed mocks reflect what your contract says dependencies should do.

For stable CI and contract testing, designed mocks are often easier to maintain because they do not drift with production data.

For more background, see:

• contract testing and mocking tools
• generating mock data from OpenAPI schemas

What you keep and what you give up

Be explicit with your team before migrating.

You give up automatic runtime capture:

• No keploy record equivalent
• No eBPF-based traffic capture
• No dependency mocks derived from production runs
• No zero-code recording workflow

If that capability is essential, keep Keploy in your toolbox.

You gain:

• Tests that read like documentation
• Scenarios that are reviewable in pull requests
• Environment switching with -e
• Data-driven runs with -d
• Mock servers you control
• One platform for API design, debugging, docs, mocks, and tests

The cost is authoring effort. The payoff is maintainability.

For broader context, see the survey of API test automation tools and the hands-on guide on how to test an API with Apidog.

If you are comparing the tools directly, read the Apidog vs Keploy comparison. If Keploy is not fitting your workflow, the best Keploy alternative roundup is also useful.

FAQ

Can Apidog import my existing Keploy recordings?

Not directly. Keploy recordings are runtime captures. Apidog works from API specs, Postman collections, and cURL commands.

The practical path is:

1. Generate or collect your API definition.
2. Import it into Apidog.
3. Use Keploy recordings as a checklist for endpoint and payload coverage.

Does Apidog record live traffic and auto-mock my database like Keploy?

No. Apidog does not capture traffic via eBPF and does not auto-generate dependency mocks from real runs.

That is Keploy’s distinct strength. Apidog generates tests and mocks from your schema, then lets you author scenarios on top.

What replaces keploy record and keploy test?

There is no direct record equivalent.

The Apidog workflow is:

1. Import a spec, Postman collection, or cURL commands.
2. Generate a starting test suite with AI.
3. Author the important scenarios.
4. Run them with apidog run.

apidog run is the CI-side replacement for keploy test.

Is it worth the extra authoring effort?

Yes, if your goal is maintainable API tests that developers can read, review, and update intentionally.

If your main requirement is zero-effort capture of real runtime behavior, including dependency mocks, Keploy still does that better.

Can I run both tools?

Yes. The tools can coexist.

A practical split is:

• Use Keploy for capture-based regression checks.
• Use Apidog for designed API scenarios, documentation, mocks, and CI test suites.

Where to start

Start with one service.

1. Export its OpenAPI spec, Postman collection, or cURL commands.
2. Import it into Apidog.
3. Generate initial test cases with AI.
4. Author one real end-to-end scenario.
5. Add an environment.
6. Add a small CSV or JSON data file.
7. Run it with apidog run.
8. Wire the command into CI.

Once that loop works, expand endpoint by endpoint.

You are trading the convenience of recording for tests your team can read, change, and trust.

To go deeper on the CLI, start with the installation guide and the command-line REST API testing walkthrough.