Feature flags
A feature flag serves a value your code reads by key, to a share of people you choose. Roll it out gradually, pull it back instantly, and keep everyone's answer stable while you do.
A feature flag is a Personalization, read through an SDK. Same object, same targeting, same selection, same rollout control, same reporting. The one thing it adds is a key your own code asks for by name.
That also means a feature flag is always applied by your code. A rollout you author in the visual editor is a Personalization; the same rollout read from your code by key is a feature flag. Two names for two ways of applying it, one mechanism.
What a flag actually serves
A flag serves a value, not just on or off. That value can be a boolean, a string, a number, or a JSON object your code branches on.
| You want | The flag serves |
|---|---|
| Turn a checkout redesign on for 10% of people | true / false |
| Try a different call-to-action | "Start free trial" / "Get a demo" |
| Change a page-size limit | 25 / 50 |
| Swap a whole pricing block | a JSON object your code renders |
Because it serves a value, a flag has an off value — what everyone receives when the flag is turned off. That is a deliberate answer, not an absence, and it is why your code can tell "deliberately off" apart from "we could not reach Intempt."
Where a flag runs
Anywhere your code runs. Your code asks for the flag by name and decides what to do with the answer.
- You give the flag a key — the name your code calls it by
- An Intempt SDK returns the value for that person
- Backend, mobile, native app, or the browser
Use a flag when the change is behaviour: which algorithm runs, which provider you call, what your API returns.
The console calls this Your code, and that is the whole of it: you ask Intempt what to show, and your own code applies it. The alternative is Visual editor, where Intempt applies the change to a web page for you.
The axis is who applies the change, not where the code runs. A mobile app is "Your code" for the
same reason a backend is: a native screen is drawn by your code, so your code is what applies the
variant. There is nothing phone-specific about it. The browser SDK sits on the visual-editor side:
it applies editor changes on a page, and since 2026-09-02 it also reads a flag by key with
variation.
If the change is the page — copy, layout, a hidden section — you want a Personalization instead: same rollout control, pointed at an element in the visual editor, no deploy and no code.
Rolling out
The rollout percentage is the share of targeted people who receive the flag. The rest get the off value.
| Widen it | Move 10% to 50%. People already served stay served, and more join them |
| Narrow it | Move 50% back to 10%. The same people who were in at 10% are in again |
| Turn it off | Set 0%. Nobody receives it, including people who had it a moment ago |
| Ship it | Set 100%. Everybody receives it |
Assignment is derived, not stored: the same person asking twice gets the same answer, and changing the percentage takes effect for people who have already been evaluated. Signing in does not move anyone — Intempt derives from the device identifier, which is present before and after.
Reading a flag from code
The SDK surface is the same three calls everywhere, and you always pass a default — what your code uses when Intempt cannot be reached.
Every SDK implements this. JavaScript, Node, Python, PHP, Swift, Android, React Native and Java
all expose variation(key, context, defaultValue), plus allFlags and the typed
boolVariation / stringVariation / numberVariation helpers. Java is not published anywhere
yet, so that one you build yourself: see the Java SDK page. Which SDKs can serve an
Experience.
// Just the value
boolean showNewCheckout = client.boolVariation("new_checkout", context, false);
// A string flag reads the same way; the default is what an outage returns
String cta = client.stringVariation("pricing_cta", context, "Get started");
// Every flag for this person, in one call
Map<String, Object> all = client.allFlags(context);You ask for a key, never for a type. Intempt works out whether that key is an experiment or a rollout, so it can change from one to the other without your code changing — which is how a flag becomes an experiment, and back, with no deploy.
The default is how an outage behaves
There is no separate call that reports why a value came back. A person held out of a rollout and a request the service never answered both give you the default you passed, so choose that default to be the behaviour you already ship. Measure the holdout in Intempt, where the exposure is recorded, rather than branching on it in your code.
Choose the key once
A flag's key is how your deployed code finds it. Renaming it silently stops matching code that is already running, so the console locks the field once the flag leaves draft.
Treat that as a convention rather than a guarantee: the lock is in the console, and the API will still accept a rename. Change a live key only by shipping code that reads the new one first.
Choose it deliberately. checkout_algorithm_v2 beats test_flag_3.
Next
- Personalizations: the same targeting, applied to a page
- Experiments: when you want to measure a difference rather than ship one
Web personalizations
Web personalizations allow you to deliver targeted content to visitors to your site using a simple JavaScript snippet. This enables a fast setup for marketers without relying on engineers to create...
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.