CI/CD Integration

Run your collections as automated integration tests inside any continuous integration pipeline. The same openpost CLI that runs locally runs in CI, fails the build on a failed assertion, and writes machine-readable reports.

TEAM & CI/CD

Overview

API Studio collections are plain JSON committed to your repository, and the CLI is a plain npm package. That means continuous integration needs no export step, no cloud sync and no service account — check out the repo, install the CLI, run the collection.

No cloud dependency — the runner is fully offline, so pipelines never call out to a vendor API

Standard exit codes — a failed assertion returns 1 and fails the build with no extra wiring

Same execution pipeline — auth, scripts, cookies, test rules and interpolation behave exactly as they do in the editor

Machine-readable output — --json and --output-file for artifacts and downstream reporting

Installing in a pipeline

The CLI ships as the openpost npm package and requires Node.js 18 or newer.

# Install globally on the runner
npm install -g openpost

# Or run it directly without installing
npx openpost run "My API" --env production

Pin the version in CI (npm install -g openpost@1.2.3) so a new release cannot change pipeline behaviour without a commit.

Exit codes

Every CI system decides pass or fail from the process exit code. No reporter plugin is required.

Code	Meaning	Pipeline result
0	All requests sent and all tests passed	Build passes
1	One or more requests or assertions failed	Build fails
2	Bad arguments, missing collection, or config error	Build fails (investigate config, not the API)

Distinguishing 1 from 2 is useful in scheduled runs: exit 2 means the pipeline itself is misconfigured rather than the API being unhealthy.

GitHub Actions

name: API tests

on: [push, pull_request]

jobs:
  api-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install API Studio CLI
        run: npm install -g openpost

      - name: Run API tests
        run: openpost run "My API" --env production --output-file results.json

      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: api-test-results
          path: results.json

if: always() keeps the report artifact even when the run fails — which is exactly when you want to read it.

GitLab CI

api-tests:
  image: node:20
  script:
    - npm install -g openpost
    - openpost run "My API" --env production --output-file results.json
  artifacts:
    when: always
    paths:
      - results.json

Jenkins

A declarative pipeline stage. The CLI needs only Node.js on the agent.

pipeline {
  agent { docker { image 'node:20' } }

  stages {
    stage('API tests') {
      steps {
        sh 'npm install -g openpost'
        sh 'openpost run "My API" --env production --output-file results.json'
      }
    }
  }

  post {
    always {
      archiveArtifacts artifacts: 'results.json', allowEmptyArchive: true
    }
  }
}

A non-zero exit from sh marks the stage failed, so no additional assertion step is needed.

CircleCI

version: 2.1

jobs:
  api-tests:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - run:
          name: Install API Studio CLI
          command: npm install -g openpost
      - run:
          name: Run API tests
          command: openpost run "My API" --env production --output-file results.json
      - store_artifacts:
          path: results.json

workflows:
  test:
    jobs:
      - api-tests

Azure Pipelines

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'

  - script: npm install -g openpost
    displayName: Install API Studio CLI

  - script: openpost run "My API" --env production --output-file results.json
    displayName: Run API tests

  - task: PublishPipelineArtifact@1
    condition: always()
    inputs:
      targetPath: results.json
      artifact: api-test-results

Secrets in CI

The encrypted vault lives in global storage (~/.openpost/global/) and is deliberately not committed, so a CI runner has no vault. Supply secrets the way your CI system already does — through its own secret store, injected as environment variables.

# GitHub Actions
- name: Run API tests
  env:
    API_TOKEN: ${{ secrets.API_TOKEN }}
  run: openpost run "My API" --env production

Keep a dedicated CI environment whose variables read from the runner environment rather than hard-coded values

Never commit real credentials to environments.json — it is a committed file

See Managing Secrets and Version Control & Team Workflow

Flags worth knowing in CI

Flag	Why it matters in a pipeline
--env <name>	Select the environment to resolve variables against
--output-file <path>	Write full results for artifact upload
--json	Machine-readable stdout for downstream parsing
--filter <glob>	Run a smoke subset on every push, the full suite nightly
--mode parallel	Faster runs for independent requests (no variable chaining)
--dry-run	Validate config and interpolation without sending traffic
--quiet	Trim log noise to a pass/fail summary

Full reference on Running Collections and CLI Overview.

Inside an existing test suite

If your pipeline already runs Jest or Mocha, the same runner is available as a Node.js API, so API checks live alongside unit tests instead of in a separate stage.

import { OpenPost } from 'openpost';

const op = new OpenPost({ workspace: process.cwd() });

test('checkout API passes its collection', async () => {
  const result = await op.runCollection('My API', {
    env: 'production',
    mode: 'sequential',
  });
  expect(result.failed).toBe(0);
});

afterAll(() => op.dispose());

The programmatic API uses the same execution pipeline as the extension — auth, scripts, cookies, test rules and variable interpolation all apply.

Common pipeline patterns

Smoke tests on every pull request

openpost run "My API" --filter "Smoke*" --mode parallel — fast feedback without the full suite

Full regression nightly

Scheduled job running the whole collection sequentially so chained requests work

Post-deploy verification

Run against the deployed environment as a release gate — exit code 1 blocks promotion

Contract check against a mock

Start a mock server in the pipeline and run the collection against it before the real backend exists

Version Control & Team Workflow → Running Collections → GUI Test Rules →