DEV Community

Cover image for How to Automate API Testing in Travis CI Using Apidog CLI ?
Hassann
Hassann

Posted on • Originally published at apidog.com

How to Automate API Testing in Travis CI Using Apidog CLI ?

Your API works on your machine. Unit tests are green. You merge, deploy, and an hour later someone reports that /checkout returns a 500 for users with an empty cart. The bug was not in the code you changed; it was in a contract two services away that nobody re-tested. Integration-level API tests close that gap, especially when they run automatically on every commit.

Try Apidog today

Travis CI watches your Git repository, starts a clean environment for every push or pull request, and runs the commands you define in .travis.yml. Most teams use it for build and unit-test workflows. You can also use it to run real HTTP checks against a running API, which is where many expensive regressions appear.

This guide shows how to run Apidog test scenarios in Travis CI with the Apidog CLI. You design and debug API tests in the Apidog desktop app, then execute those same tests headlessly in CI. You will configure Travis, install the runner, pass secrets safely, run scenarios, generate reports, and fail the build when an endpoint breaks. Download Apidog if you want to follow along.

Why run API tests in CI?

Unit tests validate isolated functions. API tests validate the request-response contract:

  • The route exists.
  • Authentication and authorization work.
  • The status code is correct.
  • The response schema matches expectations.
  • The response body contains valid values.
  • Downstream service contracts still behave as expected.

Running these checks locally helps, but it depends on developers remembering to run them and having a matching environment. CI gives you a repeatable check attached to every commit and pull request.

For API teams, this matters because breaking changes become failed assertions before they become support tickets. For background on where this fits in the delivery pipeline, see what is CI/CD. This article focuses on the Travis CI implementation.

Prerequisites

Before configuring Travis, make sure you have:

  • A Git repository connected to Travis CI. The free tier on travis-ci.com works for public and private repositories within usage limits.

Travis CI repository settings

  • An Apidog project with at least one test scenario already created and successfully run in the desktop app.
  • Node.js 16 or later. Travis provides Node through the node_js language environment.

In Apidog, a test scenario is an ordered set of API requests with assertions. For example:

  1. Log in.
  2. Create an order.
  3. Fetch the order.
  4. Delete the order.
  5. Assert each response along the way.

If you have not built a scenario yet, do that first in the Apidog app. The intended workflow is:

Design visually -> Debug locally -> Run automatically in CI
Enter fullscreen mode Exit fullscreen mode

For assertion fundamentals, see API assertions: a practical guide.

Step 1: Get your Apidog access token and scenario ID

The Apidog CLI needs two values to run your cloud-stored tests:

  1. Access token

    Generate this in your Apidog account settings under access tokens. Treat it like a password because it grants access to your project data.

  2. Test scenario ID

    Open the scenario in the Apidog desktop app and copy its ID. You can also use the Run in CI/CD option, which generates a ready-to-use command.

A generated command looks like this:

apidog run --access-token <your-access-token> -t 5564321 -e 4417023 -r cli
Enter fullscreen mode Exit fullscreen mode

The important flags are:

--access-token <token>   # Authenticates the CLI
-t 5564321               # Test scenario ID
-e 4417023               # Environment ID
-r cli                   # Reporter output format
Enter fullscreen mode Exit fullscreen mode

Before adding this to Travis, run it locally once:

npm install -g apidog-cli

apidog run --access-token <your-access-token> -t 5564321 -e 4417023 -r cli
Enter fullscreen mode Exit fullscreen mode

Confirm the scenario passes locally. This avoids wasting CI builds on token, scenario ID, or environment ID mistakes.

Step 2: Store the token securely in Travis

Do not paste your Apidog access token directly into .travis.yml. That file is committed to Git, and a leaked token can expose project data.

Use Travis repository environment variables instead.

In Travis:

  1. Open your repository.
  2. Go to repository settings.
  3. Find environment variables.
  4. Add these variables:
APIDOG_ACCESS_TOKEN=<your-token>
APIDOG_ENV_ID=<your-environment-id>
Enter fullscreen mode Exit fullscreen mode

Keep Display value in build log disabled.

Your Travis config can then reference the values safely:

$APIDOG_ACCESS_TOKEN
$APIDOG_ENV_ID
Enter fullscreen mode Exit fullscreen mode

If you prefer encrypted variables in .travis.yml, you can use the Travis CLI:

travis encrypt APIDOG_ACCESS_TOKEN="your-token-here" --add env.global
Enter fullscreen mode Exit fullscreen mode

The environment-variable UI is usually easier to manage and rotate.

Step 3: Create .travis.yml

Add this minimal Travis configuration to the root of your repository:

language: node_js

node_js:
  - "18"

cache:
  npm: true

install:
  - npm install -g apidog-cli

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

Replace 5564321 with your Apidog scenario ID.

This config does four things:

  1. Starts a Node.js 18 Travis environment.
  2. Enables npm caching.
  3. Installs the Apidog CLI globally.
  4. Runs your Apidog scenario during the script phase.

The scenario ID is safe to commit. The token is not, so it stays in Travis environment variables.

Commit and push:

git add .travis.yml
git commit -m "Run Apidog API tests in Travis CI"
git push
Enter fullscreen mode Exit fullscreen mode

Travis should start a build and run your API scenario.

For the same pattern on other CI platforms, see automate API tests in CI/CD and the GitHub Actions version.

Step 4: Fail the build when API tests fail

A CI job is useful only if test failures make the build fail.

The Apidog CLI exits with a non-zero status code when an assertion fails. Travis treats any non-zero exit code in the script phase as a failed build.

So this is enough:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

Do not do this:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli || true
Enter fullscreen mode Exit fullscreen mode

|| true hides the failure from Travis and defeats the purpose of CI testing.

You can control how the CLI behaves when one request fails with --on-error:

--on-error end       # Stop at the first failure
--on-error continue  # Continue running and report all failures
--on-error ignore    # Continue and ignore errors
Enter fullscreen mode Exit fullscreen mode

For CI, continue is usually the most useful option:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli --on-error continue
Enter fullscreen mode Exit fullscreen mode

This gives you a fuller failure report while still returning a non-zero exit code when assertions fail.

Step 5: Generate an HTML report

The CLI reporter is good for build logs:

-r cli
Enter fullscreen mode Exit fullscreen mode

For debugging failed builds, generate an HTML report too:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli,html --out-dir ./apidog-reports
Enter fullscreen mode Exit fullscreen mode

This command:

  • Prints results to the Travis log.
  • Writes an HTML report to ./apidog-reports.

To publish the report with GitHub Pages from Travis, add a deploy block like this:

deploy:
  provider: pages
  skip_cleanup: true
  github_token: $GITHUB_TOKEN
  local_dir: apidog-reports
  on:
    branch: main
Enter fullscreen mode Exit fullscreen mode

You will need to store GITHUB_TOKEN as a Travis environment variable.

If you do not want to manage artifact hosting, use Apidog cloud report upload:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli,html --upload-report
Enter fullscreen mode Exit fullscreen mode

That gives your team a report link without configuring S3, Pages, or another artifact store.

Step 6: Run against multiple environments

Use -e to select the Apidog environment.

For example, your push builds can run against staging:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_STAGING_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

A scheduled Travis cron build can run against production:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_PROD_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

Store both IDs as Travis variables:

APIDOG_STAGING_ENV_ID=<staging-env-id>
APIDOG_PROD_ENV_ID=<prod-env-id>
Enter fullscreen mode Exit fullscreen mode

Configure Travis cron jobs in the repository settings UI.

Step 7: Add data-driven API test runs

Use -d or --iteration-data to run the same scenario with CSV or JSON test data.

Example CSV:

email,password,expectedStatus
valid@example.com,correct-password,200
missing@example.com,wrong-password,401
blocked@example.com,correct-password,403
Enter fullscreen mode Exit fullscreen mode

Run the scenario with that file:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 5564321 \
  -e $APIDOG_ENV_ID \
  -d ./test-data.csv \
  -r cli
Enter fullscreen mode Exit fullscreen mode

In Travis:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -d ./test-data.csv -r cli
Enter fullscreen mode Exit fullscreen mode

Use this for edge cases such as:

  • Missing fields
  • Invalid values
  • Large payloads
  • Special characters
  • Permission variations
  • Empty carts or empty result sets

You can also use -n or --iteration-count when you want a fixed number of iterations instead of file-based data.

Step 8: Run multiple scenarios in parallel with a Travis matrix

As your suite grows, you may not want one long sequential job. Use a Travis environment matrix to run scenarios in parallel:

language: node_js

node_js:
  - "18"

cache:
  npm: true

install:
  - npm install -g apidog-cli

env:
  - SCENARIO_ID=5564321   # checkout flow
  - SCENARIO_ID=5564322   # auth flow
  - SCENARIO_ID=5564323   # search flow

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t $SCENARIO_ID -e $APIDOG_ENV_ID -r cli --on-error continue
Enter fullscreen mode Exit fullscreen mode

Each matrix job runs one scenario. The Travis build passes only when all jobs pass.

As suites grow, organize scenarios into test suites for automated API testing so the matrix does not become a hard-to-maintain list of IDs.

Why not just use curl in Travis?

You can test APIs in Travis with curl, jq, and shell scripts:

response=$(curl -s -o response.json -w "%{http_code}" https://api.example.com/checkout)

test "$response" = "200"
jq -e '.id != null' response.json
Enter fullscreen mode Exit fullscreen mode

This works for small checks, but it becomes hard to maintain when you need to validate:

  • Multi-step flows
  • Authentication
  • Nested JSON fields
  • JSON schema
  • Dynamic variables
  • Environment-specific base URLs
  • Reusable assertions
  • HTML reports

You end up duplicating API knowledge in shell scripts.

Collection runners are better, but they often introduce an export-and-sync workflow: edit tests in one tool, export JSON, commit it, and hope the exported collection stays current.

The Apidog workflow keeps tests, API design, environments, and mock servers in one place. The CLI runs the current cloud-stored scenario directly, so there is no exported file to drift. For more context, see why your Postman collections are not a source of truth and how to run Postman collections in CI without Newman.

If you are comparing tools, the best Postman alternatives for API testing roundup is a useful reference.

Travis CI notes

Travis CI is still used by many repositories, especially older open-source projects. If you are starting fresh, you may also evaluate GitHub Actions, GitLab CI, CircleCI, or Jenkins. The best CI/CD tools comparison breaks down common options.

The useful part of this setup is that the Apidog command is portable:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

That same command can run in:

  • Travis CI
  • GitHub Actions
  • GitLab CI
  • Jenkins
  • CircleCI

Only the surrounding YAML changes.

Frequently asked questions

Do I need to install the Apidog desktop app on the Travis runner?

No. The desktop app is for designing and debugging tests. Travis only needs:

  • Node.js 16+
  • apidog-cli
  • An Apidog access token
  • A scenario ID
  • An environment ID

The CLI fetches and runs the cloud-stored scenario headlessly.

Where do I find my access token?

Generate it in your Apidog account settings under access tokens.

Store it in Travis as:

APIDOG_ACCESS_TOKEN
Enter fullscreen mode Exit fullscreen mode

Do not commit it to Git.

Where do I find the scenario ID?

Open the test scenario in the Apidog desktop app and copy the ID. You can also use the built-in Run in CI/CD option to generate a command with the scenario ID included.

How do I keep the token out of the repository?

Use Travis repository environment variables and disable log display for the value.

Reference it in .travis.yml like this:

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

Alternatively, use:

travis encrypt APIDOG_ACCESS_TOKEN="your-token-here" --add env.global
Enter fullscreen mode Exit fullscreen mode

Will Travis fail when an Apidog test fails?

Yes. apidog run exits non-zero when an assertion fails, and Travis marks the build as failed.

Just do not suppress the exit code with || true.

Can I run tests against multiple environments?

Yes. Use -e with different environment IDs:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_STAGING_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_PROD_ENV_ID -r cli
Enter fullscreen mode Exit fullscreen mode

Can I use CSV or JSON test data?

Yes. Use -d:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 5564321 -e $APIDOG_ENV_ID -d ./test-data.csv -r cli
Enter fullscreen mode Exit fullscreen mode

Can I use this outside Travis CI?

Yes. The Apidog CLI command is the same across CI platforms. For GitHub Actions, see GitHub Actions.

Complete Travis CI example

Here is a practical .travis.yml you can adapt:

language: node_js

node_js:
  - "18"

cache:
  npm: true

install:
  - npm install -g apidog-cli

env:
  - SCENARIO_ID=5564321   # checkout flow
  - SCENARIO_ID=5564322   # auth flow
  - SCENARIO_ID=5564323   # search flow

script:
  - apidog run --access-token $APIDOG_ACCESS_TOKEN -t $SCENARIO_ID -e $APIDOG_ENV_ID -r cli,html --out-dir ./apidog-reports --on-error continue
Enter fullscreen mode Exit fullscreen mode

Required Travis environment variables:

APIDOG_ACCESS_TOKEN=<your-token>
APIDOG_ENV_ID=<your-environment-id>
Enter fullscreen mode Exit fullscreen mode

Optional variables if you publish reports:

GITHUB_TOKEN=<github-token>
Enter fullscreen mode Exit fullscreen mode

Wrapping up

Adding Apidog API tests to Travis CI comes down to four steps:

  1. Store your Apidog token as a Travis environment variable.
  2. Install apidog-cli in the Travis install phase.
  3. Run apidog run in the script phase.
  4. Let the CLI exit code fail the build when assertions fail.

From there, add HTML reports, data-driven runs, multiple environments, and parallel Travis matrix jobs as your suite grows.

The main advantage is keeping one source of truth. You design and debug API tests visually in Apidog, then run those same live scenarios on every commit. Your /checkout regression fails in the pull request instead of production.

Build your first scenario, download Apidog, and wire it into your next Travis build.

Top comments (0)