Creating a feature flag

Create a flag, choose whether the visual editor or an SDK applies it, set its key, roll it out, and read it from your code.

1. Create it

Experiences → Create experience. The picker asks two questions.

First: how will the change be applied?

	Choose it when
Visual editor	The change is on a web page and you want to author it by pointing at the element. No code, website only
SDK	Your own code reads the value by key and decides what to do. Works anywhere — backend, mobile, or a native app

Then: what should it do? Pick Feature flag.

The first question is about authoring, not about which machine runs your code. A mobile app is SDK, because there is no visual editor for a native screen, not because it is a phone. The browser SDK does both jobs: it applies visual-editor changes on a page, and since 2026-09-02 it also reads a flag by key with variation.

2. Set the key — SDK flags only

The key is the name your code calls the flag by.

client.boolVariation("checkout_algorithm_v2", context, false);

It appears on the flag's setup tab with a copy button. The console greys the key out once the flag leaves draft, because deployed code already calls it by that name and a rename would silently stop matching. Treat that as a convention rather than a guarantee: the API still accepts the rename.

Visual-editor flags need no key — Intempt applies the change for you.

3. Give it a value

Add a variant and set what it serves. A flag's variant carries the value your code receives: a boolean, a string, a number, or a JSON payload.

There is no off-value field in the console. What a held-back person receives is the defaultValue your own code passes to variation, so the off value lives in your codebase, not in Intempt. That is deliberate: it is also what you get when Intempt is unreachable, so the two cases take the same branch.

4. Choose what the rollout counts

Where this is asked, once it reaches your project. Pick Feature flag and a third question appears in the same dialog: What does the rollout count? Answer People (the default) or Accounts.

There is no control for it anywhere else in the console, so this is the one moment you choose. The API will accept a change while the experience is still a draft and reject it afterwards, but nothing in the UI offers you that second chance.

Pick Accounts when everyone at one company must see the same thing. Read what the rollout counts first: a person with no account is served the off value rather than being decided individually, and an account-unit flag cannot later be converted into an experiment.

5. Roll it out

The rollout control sets what share of the targeted unit receives the flag.

Start small. Widen when it looks right. Widening reaches people who have already been evaluated, so you are not limited to new visitors — and narrowing puts the same people back where they were.

6. Read it from your code

This is the shape of the call, and all eight SDKs implement it: JavaScript, Node, Python, PHP, Swift, Android, React Native and Java. See which SDKs can serve an Experience.

boolean useNewCheckout = client.boolVariation(
    "checkout_algorithm_v2", FlagContext.ofUser(userId), false);

if (useNewCheckout) {
    // Serve the new checkout.
}
// The default you pass is what you get when the flag is off, the key is
// unknown, or the service cannot be reached.

Always pass a default. It is what your code uses when Intempt cannot be reached, and it means a network problem degrades to your existing behaviour rather than an exception.

7. Turn it off

Set the rollout to 0%. Everyone receives the off value immediately, including people who had the flag a moment earlier. No deploy.

SDKs

Java reads a flag by key. Every other SDK page below documents event capture and consent, not flag reads — the optimization call is not implemented in them:

JavaScript · Node.js · Python · PHP · Android · iOS · React Native

On this page