Skip to main content
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.
TypeUse for
priceMonetary values: IAP prices, subscription tiers, soft currency amounts
frequency”Show every N rounds / sessions” cadence values
multiplierXP multipliers, reward boosts, progression modifiers
colorHex or RGB color values
toggleBoolean feature flags
textCopy variants, button labels, strings
numberAny 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

1

Open the Levers page

Navigate to Levers in the backoffice sidebar. You’ll see all currently detected levers grouped by endpoint.
2

Click + New lever

This opens the lever creation wizard.
3

Select the endpoint

Pick the config-candidate endpoint that returns the parameter you want to test.
4

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.
5

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.
6

Save

The lever appears in the catalog immediately and is ready to be tested.

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.
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.