Documentation Menu

Project Configurations

In RegressionBot, a project serves as both a baseline namespace and a saved execution configuration. Once created, a project locks in its testing parameters — preventing baseline drift and ensuring that every run compares against the same set of pages, devices, and masks.

Projects operate in managed mode (where screenshots are stored as baselines and compared on subsequent runs) by default. They work the same way across all interfaces: the REST API, the Node.js SDK, and MCP agentic tools. The first run against a new project name creates the project and saves its configuration. Repeat runs can omit all parameters and load the saved configuration automatically.

Project Configuration Locking

Configuration locking applies exclusively to managed mode runs (where no baseOrigin is supplied and screenshots are stored as baselines for comparison on future runs). In live-vs-live mode (where baseOrigin is present), parameters are always accepted since there are no stored baselines to protect.

First Run (Creation)

Executing a job for a new project name automatically creates the project entity. The parameters you provide (testOrigin, paths, devices, masks) are saved as the configuration for all future runs.

Subsequent Runs (Enforcement)

Subsequent runs against the same project name must either omit parameters (inheriting them from the stored configuration) or pass identical values. Providing differing parameters returns a 400 validation error.

Param Matching Rules

When verifying parameters, RegressionBot compares the following fields against the stored project configuration. Only fields you supply are checked — omitting a field is always allowed.

FieldComparison
testOriginExact string match
devicesSet equality (order-insensitive)
pathsSet equality on path values — label is ignored
masksSet equality on CSS selector strings
sitemapUrlExact string match
scansSet equality on pattern values
concurrencyNot checked — does not affect what is captured

Baseline Invalidation & Rollback

When you need to update a project's parameters (for example, adding a new page path or a new device), the existing baselines are no longer compatible with the new configuration.

To update a project's configuration via the REST API, use PUT /project/{name}. This updates the stored config and invalidates existing baselines:

curl -X PUT https://api.regressionbot.com/project/my-project \
  -H "x-api-key: $REGRESSIONBOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"testOrigin": "https://new-origin.com", "devices": ["Desktop Chrome"]}'

This triggers a baseline invalidation — because baselineVersion changes, the next run creates new baselines from scratch. All results on the next job will show isNewBaseline: true. Run the job a second time to begin detecting regressions.

What happens on invalidation:

  • No destructive deletes: Historical baseline screenshots are never deleted when a configuration changes.
  • Superseded in place: The next job run treats all screenshots captured before the invalidation as new baselines (isNewBaseline: true).
  • New baselines on next run: After PUT /project/{name}, the next run re-baselines everything. Run it a second time to start detecting regressions against the updated baselines.

REST API

Five dedicated endpoints let you manage and run projects: POST /project, GET /project/{name}, PUT /project/{name}, POST /project/{name}/run, and GET /projects.

Note: Projects are also created implicitly — the first POST /crawl or POST /project/{name}/run call with a new project name automatically creates the project and saves its configuration. There is no separate explicit creation step required.

GET/projects

List all projects belonging to your organisation.

curl https://api.regressionbot.com/projects \
  -H "x-api-key: YOUR_API_KEY"

Response (200)

[
  {
    "orgId": "org_abc123",
    "name": "my-billing-app",
    "testOrigin": "https://staging.myapp.com",
    "devices": ["Desktop Chrome", "iPhone 12"],
    "lastRunAt": "2024-06-01T10:00:00.000Z",
    "lastJobId": "550e8400-e29b-41d4-a716-446655440000",
    "createdAt": "2024-05-01T09:00:00.000Z",
    "updatedAt": "2024-06-01T10:00:00.000Z"
  }
]
GET/project/{name}

Retrieve the full saved configuration for a named project.

curl https://api.regressionbot.com/project/my-billing-app \
  -H "x-api-key: YOUR_API_KEY"

Response (200)

{
  "orgId": "org_abc123",
  "name": "my-billing-app",
  "testOrigin": "https://staging.myapp.com",
  "sitemapUrl": "https://staging.myapp.com/sitemap.xml",
  "paths": [
    { "path": "/invoice", "label": "Invoice Page" },
    { "path": "/settings" }
  ],
  "devices": ["Desktop Chrome", "iPhone 12"],
  "masks": [".ad-banner", "#cookie-notice"],
  "concurrency": 5,
  "createdAt": "2024-05-01T09:00:00.000Z",
  "updatedAt": "2024-06-01T10:00:00.000Z",
  "lastRunAt": "2024-06-01T10:00:00.000Z",
  "lastJobId": "550e8400-e29b-41d4-a716-446655440000"
}
404Project not found
403Project belongs to a different organisation
POST/project/{name}/run

Start a visual regression job using the saved project configuration. The request body is optional — omit it entirely to run with the stored config unchanged.

Parameter-less run (most common in CI)

Send no body. RegressionBot loads the stored configuration for this project and starts the job.

curl -X POST https://api.regressionbot.com/project/my-billing-app/run \
  -H "x-api-key: YOUR_API_KEY"

Run with optional overrides

You can override specific fields for a single run without modifying the stored configuration. This is useful for testing against a different testOrigin (for example, a feature branch preview URL) while keeping all other parameters from the saved config.

Note: /project/{name}/run allows runtime overrides (e.g. testOrigin, autoApprove). The /crawl endpoint enforces strict config locking — if you supply params that differ from the stored project config, the request is rejected.
curl -X POST https://api.regressionbot.com/project/my-billing-app/run \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "testOrigin": "https://pr-42.preview.myapp.com",
    "concurrency": 10
  }'

Auto-approve (baseline seeding)

Set autoApprove: true to automatically promote captured screenshots to baselines without a manual review step. Use this when seeding baselines for the first time or after a planned redesign.

curl -X POST https://api.regressionbot.com/project/my-billing-app/run \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "autoApprove": true }'

Request Body (all fields optional)

FieldTypeDescription
testOriginstringOverride the origin to test for this run only.
sitemapUrlstringOverride the sitemap URL for this run only.
baseOriginstringOverride to switch this run to live-vs-live mode.
devicesstring[]Override the device list for this run.
paths{path, label?}[]Override the specific paths to check.
scans{pattern}[]Override sitemap discovery glob patterns.
masksstring[]Override CSS selectors to blank out before capture.
concurrencyinteger (1–20)Override the number of parallel workers. Does not affect config locking.
autoApprovebooleanWhen true, automatically promotes captures to baselines without a review step.

Response (200)

{
  "message": "Visual regression job started",
  "jobId": "550e8400-e29b-41d4-a716-446655440000"
}

Use the returned jobId to poll GET /job/{jobId} for status updates. The job progresses through PROCESSING → COMPLETED.

400Invalid project name, or override params conflict with stored config
404Project not found
403Project belongs to a different organisation

How to Configure

1. Creating a project (first run)

The first run against a new project name creates the project and saves its parameters. You can do this via the REST API or the Node.js SDK.

REST API

curl -X POST https://api.regressionbot.com/crawl \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "project": "my-billing-app",
    "testOrigin": "https://staging.myapp.com",
    "devices": ["Desktop Chrome", "iPhone 12"],
    "paths": [
      { "path": "/invoice" },
      { "path": "/settings" }
    ]
  }'

Node.js SDK

import { RegressionBot } from 'regressionbot';

const client = new RegressionBot(process.env.REGRESSIONBOT_API_KEY!);

const job = await client
  .test('https://staging.myapp.com')
  .forProject('my-billing-app')
  .on(['Desktop Chrome', 'iPhone 12'])
  .paths(['/invoice', '/settings'])
  .run();

2. Parameter-less reruns

Once a project exists, you can trigger a run by providing only the project name. RegressionBot loads the saved configuration automatically. This is the recommended pattern for recurring CI jobs.

REST API — dedicated endpoint

# Loads the saved config for my-billing-app
curl -X POST https://api.regressionbot.com/project/my-billing-app/run \
  -H "x-api-key: YOUR_API_KEY"

REST API — via /crawl

# Also works: omit all params except project name
curl -X POST https://api.regressionbot.com/crawl \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "project": "my-billing-app" }'
Node.js SDK
import { RegressionBot } from 'regressionbot';

const client = new RegressionBot(process.env.REGRESSIONBOT_API_KEY!);

// No origin, devices, or paths — loads config from 'my-billing-app'.
const job = await client
  .forProject('my-billing-app')
  .run();

3. CI integration example

The following workflow runs a visual regression check on every push to a staging environment, then fails the build if regressions are found. The GET /job/{jobId} endpoint is the job status endpoint — poll it until status reaches COMPLETED, APPROVED, or FAILED.

# .github/workflows/visual-regression.yml
name: Visual Regression Check

on:
  deployment_status:

jobs:
  visual-check:
    if: github.event.deployment_status.state == 'success' && github.event.deployment_status.environment == 'staging'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run visual regression
        env:
          REGRESSIONBOT_API_KEY: ${{ secrets.REGRESSIONBOT_API_KEY }}
        run: |
          # Start the job using the project's saved config
          RESPONSE=$(curl -s -X POST https://api.regressionbot.com/project/my-billing-app/run \
            -H "x-api-key: $REGRESSIONBOT_API_KEY")

          JOB_ID=$(echo $RESPONSE | jq -r '.jobId')
          if [ -z "$JOB_ID" ] || [ "$JOB_ID" = "null" ]; then
            echo "::error::Failed to start job: $RESPONSE"
            exit 1
          fi
          echo "Job started: $JOB_ID"

          # Poll until complete (max 10 minutes)
          STATUS=""
          for i in $(seq 1 60); do
            sleep 10
            STATUS=$(curl -s https://api.regressionbot.com/job/$JOB_ID \
              -H "x-api-key: $REGRESSIONBOT_API_KEY" | jq -r '.status')
            echo "Status: $STATUS"
            if [ "$STATUS" = "COMPLETED" ] || [ "$STATUS" = "APPROVED" ] || [ "$STATUS" = "FAILED" ]; then
              break
            fi
          done

          if [ "$STATUS" = "FAILED" ]; then
            echo "::error::Visual regression job failed"
            exit 1
          fi

          if [ "$STATUS" != "COMPLETED" ] && [ "$STATUS" != "APPROVED" ]; then
            echo "::error::Job timed out after 10 minutes (last status: $STATUS)"
            exit 1
          fi

          # Check for regressions
          REGRESSIONS=$(curl -s https://api.regressionbot.com/job/$JOB_ID/summary \
            -H "x-api-key: $REGRESSIONBOT_API_KEY" | jq '.regressionCount // 0')
          if [ "$REGRESSIONS" -gt 0 ]; then
            echo "::error::$REGRESSIONS regression(s) detected"
            exit 1
          fi

Troubleshooting

400 Bad RequestParameter mismatch

Why this happens: You triggered a job against an existing project but supplied parameters — such as testOrigin, devices, or paths — that differ from the saved config. The error message names the specific fields that conflict.

Solution: Either omit those parameters so the saved config is used automatically, or use POST /project/{name}/run with no body. To intentionally change the config (for example, to add new pages), use the MCP update_project tool or PUT /project/{name} via REST — note that updating the config invalidates all existing baselines.

404 Not FoundProject not found

Why this happens: You called GET /project/{name} or POST /project/{name} /run but no project with that name exists in your organisation.

Solution: Check the name for typos. Use GET /projects to list all projects in your org. To create a project, run a managed-mode job against the name via POST /crawl with the full parameter set.

400 Bad RequestMissing testOrigin on parameter-less run

Why this happens: You called POST /project/{name} /run with no body, but the project exists without a saved testOrigin. This can happen if the project was created before the config-locking feature was introduced.

Solution: Run a full job via POST /crawl with the project name and all required parameters. This saves the config to the project for future parameter-less runs.

isNewBaseline: trueAll results show isNewBaseline: true

Why this happens: This is expected on the first run for a new project — no comparison has been made yet, baselines were created. It also occurs after a PUT /project/{name} update, which resets baselineVersion and forces re-baselining.

Solution: Run the job a second time to detect regressions against the newly created baselines. Use POST /approve (or the approve_job MCP tool) after the first run if you want to lock in these screenshots as baselines immediately without a second run.