> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fleack.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Levers: Declaring Testable Parameters in Your API

> Learn what levers are in Fleack, how AI and heuristics detect them automatically, and how to create one manually using the New Lever wizard.

A **lever** is a specific parameter inside an endpoint's response body that you've declared as testable. It's the bridge between a raw API response and a running experiment: before you can A/B test a value, you need to tell Fleack which JSON path it lives at and what kind of value it represents. Levers give your growth team a clean, named catalog of everything that can be safely varied — without any app code changes.

## Identifying levers by JSON path

Every lever is tied to a JSON path within a `config-candidate` endpoint's response body. The path tells Fleack exactly where to read the current value and where to inject a variant value at runtime.

Common examples from mobile game backends:

* `data.gems_reward` — the number of gems awarded for completing a daily reward
* `ads.interstitial_frequency` — how often an interstitial ad is shown (e.g. every N rounds)
* `data.rewards[*].value` — the value field across every item in a rewards array

The `[*]` wildcard lets a single lever target every element in an array at once, which is useful when you want to scale all reward values together rather than managing one lever per index.

## Lever types

Every lever has a type. The type drives how the backoffice presents the lever and its variant values — it doesn't affect how Fleack injects the value at runtime.

| Type         | Use for                                                                |
| ------------ | ---------------------------------------------------------------------- |
| `price`      | Monetary values: IAP prices, subscription tiers, soft currency amounts |
| `frequency`  | "Show every N rounds / sessions" cadence values                        |
| `multiplier` | XP multipliers, reward boosts, progression modifiers                   |
| `color`      | Hex or RGB color values                                                |
| `toggle`     | Boolean feature flags                                                  |
| `text`       | Copy variants, button labels, strings                                  |
| `number`     | Any other numeric value that doesn't fit a more specific type          |

## How levers are discovered

Fleack surfaces candidate levers through three mechanisms — you don't need to hand-code anything:

**AI auto-detection** — when AI enrichment is enabled, Fleack sends captured response bodies through a GPT-class model that identifies semantically meaningful parameters and suggests the right lever type and label. This is the fastest path to a populated lever catalog.

**Heuristic detection** — for every `config-candidate` endpoint, Fleack automatically exposes every scalar value in the response body as a candidate lever. This ensures full coverage even if AI enrichment is not enabled.

**Manual creation** — you create a lever yourself via the **+ New lever** wizard. This is the right choice when auto-detection missed something, or when you want a precisely scoped path (for example, `data.rewards[*].value` rather than each individual reward value as a separate lever).

## Creating a lever manually

<Steps>
  <Step title="Open the Levers page">
    Navigate to **Levers** in the backoffice sidebar. You'll see all currently detected levers grouped by endpoint.
  </Step>

  <Step title="Click + New lever">
    This opens the lever creation wizard.
  </Step>

  <Step title="Select the endpoint">
    Pick the `config-candidate` endpoint that returns the parameter you want to test.
  </Step>

  <Step title="Choose the parameter">
    Fleack shows you the captured response body. Click the field you want (e.g. `data.gems_reward = 30`), or type the JSON path directly.
  </Step>

  <Step title="Set label, type, and starter values">
    Give the lever a human-readable label (e.g. "Gems reward amount"), choose its type (number, price, frequency, color, toggle, or text), and optionally add a few variant values to pre-populate your first test.
  </Step>

  <Step title="Save">
    The lever appears in the catalog immediately and is ready to be tested.
  </Step>
</Steps>

## A note on displayed values

The lever catalog always shows you the value your **backend actually returned** — not what a running test may be rewriting. If you have a live test on `data.gems_reward`, the catalog still shows `30` (the real backend value), not the variant value being served to test participants.

This is intentional: the catalog is your source of truth for production state, not a view of what any individual user sees.

<Tip>
  When in doubt about which JSON path to use, click through to the endpoint detail page to browse a full captured response sample. You can copy paths directly from there into the lever wizard.
</Tip>