Feature flags

A feature flag is a named switch with one or more possible values. This page covers everything a flag can do.

Flag kinds

When you create a flag you choose its kind — the type of value it serves:

Kind	Serves	Use it for
Boolean	true / false	On/off switches — the most common case.
String	Any text value	Multi-variant choices, e.g. control / red / blue.
Number	A numeric value	Tunable limits, e.g. a page size or timeout.
JSON	An object	Structured config delivered as one flag.

The kind is fixed once the flag is created.

Variations

A variation is one possible value the flag can serve. Each has a key, a name, a value and an optional colour label.

• Boolean flags have two fixed variations — true and false.
• String, number and JSON flags let you define your own variations. Edit them in the Variations section of the flag detail page.

Every other feature — rules, rollouts, fallthrough — works by choosing which variation to serve.

Environments

Each flag has completely independent state in development, staging and production. The environment switcher in the top bar selects which one you are viewing. A typical workflow is to build and verify targeting in development, check it in staging, then reproduce it in production.

For each environment a flag stores:

• Enabled — the master on/off switch.
• Rollout percentage — see below.
• Targeting rules — see below.
• Fallthrough — the variation served when no rule matches.
• Off variation — the variation served when the flag is disabled.

How an evaluation is decided

When your app evaluates a flag for a user, RestFlags resolves it in this order:

1. Prerequisites — if any prerequisite is unmet, serve the off variation (reason: prerequisite_failed).
2. Enabled? — if the flag is off, serve the off variation (reason: flag_off).
3. Targeting rules — evaluated top to bottom; the first rule whose conditions all match wins (reason: rule_match).
4. Fallthrough — if no rule matches, serve the fallthrough variation, subject to the rollout percentage (reason: fallthrough or fallthrough_off).

The reason is returned in every API response so you can see exactly why a user got the value they did.

Targeting rules

A targeting rule serves a chosen variation to a matching audience. A rule is:

• One or more conditions, combined with AND (all must match).
• A served variation.
• An optional rollout percentage applied within the rule.

Rules are ordered — drag to reorder them. The first matching rule wins.

Conditions and operators

Each condition tests one attribute of the user context against some values:

Operator	Meaning
is one of (in)	Attribute equals one of the listed values.
is not one of (not_in)	Attribute is none of the listed values.
starts with	String attribute begins with a value.
ends with	String attribute ends with a value.
contains	String attribute contains a value.
in segment (matches_segment)	User matches a named segment.

Attributes come from the user object you send when evaluating. Common ones are suggested in the editor — user.id, user.email, user.plan, user.country, user.role — but any attribute you send can be targeted.

Example

Rule 1 — serve true when user.plan is one of pro, enterprise and user.country is one of US, CA.

Users on a pro or enterprise plan in the US or Canada get the feature; everyone else falls through.

Rollout percentage

The rollout percentage serves the fallthrough variation to a stable, random slice of users. Set it to 25 and roughly a quarter of users who reach the fallthrough get the feature — and the same users stay in that slice on every evaluation, so the experience is consistent.

A rollout can also be attached to an individual rule, so a rule matches an audience and only rolls the feature out to a fraction of it.

Prerequisites

A prerequisite makes one flag depend on another. A flag can require another flag to be serving a specific value before it evaluates at all.

For example, new-checkout might require payments-v2 to be true. If the prerequisite is unmet, new-checkout serves its off variation with reason: prerequisite_failed. The detail page shows each prerequisite's current met / unmet status.

Flag metadata

The settings panel on the detail page holds metadata that does not affect evaluation:

• Name and description — human-readable context.
• Tags — labels for filtering and search.
• Maintainer — the person responsible for the flag.

Archiving and deleting

• Archive — hides a flag from the main list while preserving it and its history. Archived flags can be restored.
• Delete — permanently removes the flag from every environment. This cannot be undone.

Both actions are recorded in the Audit log.

Activity

Every flag detail page has an activity view showing its full change history — who toggled it, who edited its rules, and when.