How to Use the Apidog CLI in Cline

Cline works in a loop: it plans a change, edits files, runs commands, reads output, and decides what to do next. Your API tests should be part of that loop instead of waiting in an Apidog GUI for someone to click Run.

Try Apidog today

The setup is one project rule. apidog-cli is an npm package that runs Apidog test scenarios from the terminal. Once it is installed and Cline knows the command, Cline can run API tests like unit tests:

1. Run the scenario.
2. Read the terminal output and exit code.
3. Fix the implementation when the run fails.
4. Re-run the scenario.

Before continuing, install and authenticate the CLI. How to install the Apidog CLI with an AI coding agent covers npm installation, authentication, and a first run with Cline.

This guide assumes the following command prints a version number:

apidog --version

It also assumes you have already authenticated your machine with Apidog.

Which Cline this is about

Cline is an open-source autonomous coding agent available as a VS Code extension, with JetBrains and CLI options as well. It reads your repository, creates a plan in Plan mode, then edits files and runs shell commands in Act mode.

Cline runs against your local codebase. If you use the Cline panel in VS Code and can see diffs and terminal output during a task, this guide applies to your workflow. For setup basics, see How to use Cline.

The important Cline feature here is project rules. Put the API test command in .clinerules/, and Cline can apply it across future tasks instead of relying on a one-time chat instruction.

Step 1: Add an Apidog rule to .clinerules/

Cline loads project rules from a .clinerules/ directory at the workspace root before it starts a task. It reads .md and .txt files in that directory and combines them into its instruction set.

You can also use a single .clinerules file, but a directory is easier to maintain as your project rules grow. See the Cline rules reference.

Create this file:

.clinerules/apidog.md

Add a rule block with your real scenario and environment IDs:

# API testing with Apidog

- To test the API, run the Apidog CLI, not curl or ad-hoc scripts.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- The scenario ID and environment ID come from Apidog's CI/CD tab. Use those exact values.
- Exit code 0 means every assertion passed. Non-zero means a failure; the exit code is the source of truth, not your summary.
- The machine is already authenticated via `apidog login`. Never add --access-token and never put a token in this file.
- If a flag is unknown, run `apidog run --help` and use the exact flag from there.

Version-control this file. That makes the test command available to every teammate and every future Cline task that uses the repository.

Step 2: Copy the generated command from Apidog

Do not guess scenario IDs or CLI flags.

In Apidog:

1. Open the test scenario.
2. Open the CI/CD tab.
3. Copy the generated apidog run command.

For example:

apidog run -t 8291 -e 42 -r cli

In this command:

• -t 8291 is the test scenario ID.
• -e 42 is the environment ID.
• -r cli prints results directly in the terminal.

Paste your generated IDs into .clinerules/apidog.md. For available options, see the apidog run command reference.

Step 3: Ask Cline to run the scenario

Start a new task in Cline after adding the rule. Cline loads .clinerules/ when the task begins.

You can ask directly:

Run the Apidog test scenario and tell me the result.

Cline should use the apidog run command defined in your rules. Whether it asks for approval depends on your Cline auto-approve settings.

For a read-only test scenario against staging:

• Cline may classify the command as safe.
• If safe-command auto-approval is enabled, it can run without prompting.
• Otherwise, approve the command manually.

The -r cli reporter is useful for agents because it prints request-by-request results and a final summary in the terminal output Cline can read.

Step 4: Use the report to drive the next fix

When the scenario fails, inspect the terminal output. With -r cli, Cline can see:

• Each request sent by the scenario.
• Each assertion result.
• The failed status code, field, or value.
• Expected versus actual values.

That output gives Cline actionable failure context for the next edit-test-fix pass.

To also generate a browser-viewable report, add the HTML reporter:

apidog run -t 8291 -e 42 -r cli,html

The html reporter writes a self-contained report to:

./apidog-reports

Keep cli in the reporter list. Cline needs inline terminal output to interpret the result during the task.

For more reporter formats, including JUnit output for CI dashboards, see:

• The complete Apidog CLI guide
• The Apidog CLI test reports guide

Put API tests inside Cline's edit-test-fix loop

Once the command is in .clinerules/, Cline can treat an API scenario as a normal validation step.

For example, suppose Cline modifies a checkout handler:

1. It edits the response-building code.
2. It runs the Apidog scenario against staging.
3. It checks the exit code.
4. If the run is green, it continues.
5. If the run is red, it reads the failed assertion.
6. It updates the handler and runs the scenario again.

This turns your Apidog scenario into part of the same loop Cline already uses for unit tests.

You still create and maintain scenarios visually in Apidog. Cline handles execution and uses the result to validate its changes. For the broader workflow, see:

• How to use AI agents for API testing
• The Apidog AI test harness

Verify that Cline actually ran the CLI

Do not rely only on an agent summary. Verify the command, output, and exit code.

1. Confirm the command appears in the task output

Cline shows executed commands and terminal output in the task view.

Look for a literal command similar to:

apidog run -t 8291 -e 42 -r cli

If Cline claims the tests ran but you cannot find the command and its output, ask it to run the scenario again and show the raw terminal output.

2. Confirm the exit code

Ask Cline:

What was the exit code of that apidog run command?

apidog run exits with:

• 0 when every assertion passes.
• A non-zero code when one or more assertions fail.

Treat the exit code as the source of truth. If Cline says “tests passed” but the process returned a non-zero code, the test run failed.

3. Confirm Cline used the correct scenario

An error such as scenario not found usually means the scenario or environment ID is wrong.

Check these values against:

1. The command generated in Apidog's CI/CD tab.
2. Your .clinerules/apidog.md file.

The IDs in the generated Apidog command are the values to keep in the rule.

Optional: Connect the Apidog MCP server

The CLI is enough to run API scenarios. MCP adds another capability: it can provide API specification context while Cline writes code.

Cline supports the Model Context Protocol. In the VS Code extension:

1. Open the MCP Servers icon in the Cline panel.
2. Select Configure.
3. Select Configure MCP Servers.
4. Add the server under mcpServers in cline_mcp_settings.json.

You can also install MCP servers through the Cline MCP Marketplace. See the Cline MCP documentation.

The Apidog MCP server exposes API specifications over MCP. In practice:

• The Apidog CLI runs test scenarios.
• The Apidog MCP server gives Cline API schema context.

Cline is interactive, so it is not a replacement for a headless CI runner. To run the same apidog run command without Cline in a pipeline, see:

• Apidog CLI in GitHub Actions
• The Apidog CLI CI/CD pipeline guide

Troubleshooting common Cline setup failures

Cline ignores the rules file

Check all of the following:

• The directory is named exactly .clinerules.
• The directory is at the workspace root.
• The rule file ends in .md or .txt.
• You started a new Cline task after changing the rules.

Starting a fresh task forces Cline to reload project rules.

Cline adds an access token

If Cline adds --access-token, it is likely guessing from public examples.

Keep this instruction in your rule:

The machine is already authenticated via `apidog login`. Never add --access-token and never put a token in this file.

Do not store credentials in .clinerules/. For authentication details, see the Apidog CLI authentication guide.

Cline invents a CLI flag

An unknown option error means the command contains a flag unsupported by your installed CLI version.

Tell Cline to check the local help output:

apidog run --help

Then use the exact flag shown by your installed version.

Cline reports success after a failed run

Always compare the summary with the exit code.

If they disagree, trust the exit code:

0       = passed
non-zero = failed

This is why the exit-code rule should live in both your .clinerules/apidog.md file and your verification workflow.

From daily agent usage to a tested API loop

Install apidog-cli once, add the generated apidog run command to .clinerules/apidog.md, and Cline can run API tests while it works on your code.

That moves API validation earlier in the workflow: Cline can catch a broken endpoint during the same task that introduced the change.

You continue building scenarios visually in Apidog. Cline runs those scenarios from the terminal whenever the task needs API validation.

Download Apidog, create a scenario, copy its apidog run command into .clinerules/apidog.md, and start a new Cline task.