> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.tech/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 saved on that config and linked to the selected environment.

## How project defaults are built

Project-level defaults are constructed from:

1. The application's default environment selection.
2. Config environment overrides, aggregated into a single `configsByEnvironment` map keyed by environment ID, then by config slug.

If multiple configs 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 the config.
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`.