> For the complete documentation index, see [llms.txt](https://docs.abtasty.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.abtasty.com/server-side/command-line-interface/resource-loader/feature-experimentation/variation.md).

# Variation

Schema, including its fields, nested structure, and relationships

#### Definition

A **Variation** is a traffic bucket inside a variation group. Exactly one variation per group is the **reference** (control). Non-reference variations may define **Modifications** (e.g., setting feature flags or remote config variables) applied to users assigned to that variation.

#### Payload Properties

When creating/updating a Variation, the payload includes the following fields:

* **`id`** (String, *optional*) – The variation unique ID. Include this only when updating an existing variation.
* `name` (String, **required**) — Label for the variation.
* `reference` (Boolean, **required**) — Exactly one `true` per group.
* `allocation` (Integer, **required**) — Percentage (0–100) of the group’s traffic.
* `modifications` (Object, optional) — Changes applied to this variation:
  * `type` (String, **required when present**) — e.g., `"FLAG"` (or `"VARIABLES"` if supported).
  * `value` (Object, **required when present**) — Key/value pairs to set (flag names or config keys).

**Example Variation Payload:** Creating a new variation with a name, allocating 50% of traffic, and including some flags:

```json
{
  "name": "Variation 1",
  "reference": false,
  "allocation": 50,
  "modifications": {
    "type": "FLAG",
    "value": {
      "flag_created_with_resource_loader": "blue",
      "recommendations.limit": 6
    }
  }
}

```

#### Response Fields

When a Variation is returned by the API/Resource Loader (nested under its variation group), you’ll see the server-assigned ID and the resolved definition:

* `id` (String) — Unique variation identifier.
* `name` (String) — Variation name.
* `reference` (Boolean) — Whether this is the control.
* `allocation` (Integer) — Traffic allocation (0–100).
* `modifications` (Object) — Resolved modifications:
  * `type` (String) — e.g., `"FLAG"`.
  * `value` (Object|Array) — Effective values. Some implementations return an empty object/array for the control when no changes apply.

**Example Response**

```json
{
  "allocation": 50,
  "id": "variation_id",
  "modifications": {
    "type": "FLAG",
    "value": []
  },
  "name": "Original",
  "reference": true
}
```

#### Error Codes

Variations use the same set of error codes as modifications (and other resources), adjusted to the context of campaigns and variations:

* **InvalidPayload** – The variation data was missing required fields or had invalid values.
* **ParentNotFound** – The specified parent campaign was not found (e.g., the `$_parent_id` campaign ID is invalid).
* **PermissionDenied** – The user is not allowed to create or modify variations in this campaign.
* **DuplicateRef** – A variation with the same reference already exists (for example, a duplicate variation name in the same campaign).
* **InvalidDependency** – A related resource is missing (for instance, trying to create a variation in a campaign that doesn’t exist or isn’t accessible).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.abtasty.com/server-side/command-line-interface/resource-loader/feature-experimentation/variation.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.