> ## Documentation Index
> Fetch the complete documentation index at: https://qatech-cursor-setup-dev-environment-6819.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Config Environment Overrides

> How config environment overrides are stored, merged, and resolved at runtime.

This page explains how config environment overrides are stored, merged, and resolved at run time.

## Overview

Config environment overrides let you assign different payloads for the same config slug based on the selected environment.

The system supports two override layers:

* Environment-scoped overrides via `configsByEnvironment`.
* Plan-wide overrides via `configs`.

When both are present for the same config slug, the plan-wide value wins.

## Add config overrides in the UI

In the SaaS app, you can configure environment-scoped overrides directly on a config:

1. Go to your project's Configs page.
2. Open an existing config and click Edit.
3. In **Environment Overrides**, select the application for this config.
4. Under **Add Environment Override**, choose the environment you want to override and click **Add**.
5. Update the override fields for that environment.
6. Click **Save** on the config form.

After save, the override is persisted to `configs.environment_overrides` for that environment ID.

## Where overrides are stored

Config rows in `public.configs` include:

* `data`: base config payload.
* `environment_overrides` (`jsonb`): `environment UUID -> config payload`.
* `application_id` (`uuid | null`): optional application scope used by the SaaS Config editor to limit selectable environments.

`environment_overrides` is persisted directly on each config row, not in a separate table.

## How project defaults are built

Project-level defaults are constructed from:

1. Application default environments (`applications.default_environment_id`).
2. Config row `environment_overrides`, aggregated into a single `configsByEnvironment` map keyed by environment ID, then by config slug.

If multiple config rows define overrides for the same environment, each config slug is merged into that environment map.

## Merge order across project, test plan, and run request

Before execution, parameters are merged in this order, with later values overriding earlier values:

1. Project parameters.
2. Test plan parameters.
3. Runtime request parameters (`triggerData.parameters`).

This merged object is written to the blueprint and used during test preparation and execution.

## Effective config resolution order

For a given test and config slug, resolved value precedence is:

1. Base payload from `configs.data`.
2. `parameters.configsByEnvironment[environmentId][configSlug]` (if the test has an environment ID and a matching override exists).
3. `parameters.configs[configSlug]`.

This means `configs` always overrides `configsByEnvironment` for the same slug.

## Runtime API shape

`POST /v1/run` accepts config overrides under `parameters`:

```json theme={null}
{
  "testPlanShortId": "pln_my-plan_123",
  "parameters": {
    "configsByEnvironment": {
      "b73dc3c3-92b0-4f15-83b0-500c42ecd95c": {
        "cfg-login_abc123": {
          "username": "preview-user@example.com",
          "apiToken": "preview-token"
        }
      }
    },
    "configs": {
      "cfg-login_abc123": {
        "username": "global-user@example.com",
        "apiToken": "global-token"
      }
    }
  }
}
```

In this payload, the effective value for `cfg-login_abc123` is the `configs` entry because it has higher precedence.

## Key format and normalization notes

* `configs` and `configsByEnvironment` preserve raw map keys as provided.
* Config identifiers are treated as string keys (typically config short IDs or slugs).
* Environment-specific overrides are only considered when execution has a concrete `environmentId`.