Skip to main content
Targeting rules let a flag resolve to different values based on device attributes. Rules are evaluated in priority order (lowest first); the first rule whose conditions all match — and whose rollout percentage admits the device — wins. If no rule matches, the flag’s default value for the environment is returned.
Targeting rules are available on Pro, Business, and Enterprise plans. See Tier limits.

Authentication

Rule endpoints live under the tenant flags API and use the same authentication as Get Flags: The dashboard UI manages rules through equivalent session-authenticated endpoints; the routes below are the API surface for server-side automation.

List rules

Returns all rules for the flag, sorted by priority (ascending). Response

Create a rule

New rules are appended to the end of the priority order. Request body
Response — the created FlagRuleResponse (same shape as list).

Update a rule

All fields are optional; only provided fields are changed. priority can also be set directly here, though reorder is the safer way to change ordering.

Delete a rule

Response204 No Content

Reorder rules

Request body
ruleIds must contain exactly the IDs of all rules for the flag — array index becomes the new priority. Returns the updated rule list sorted by priority. Priorities are updated atomically in a transaction.

Conditions

Each condition is:

Targeting attributes

Attributes match against device context headers sent by the SDK on flag requests: If the device does not provide a value for a condition’s attribute, that condition fails (and the rule does not match).

Operators

Rollout percentage

When rolloutPercentage is below 100, matching devices are admitted deterministically: a stable hash of deviceId + flagKey buckets each device into 0–99, and buckets below the percentage pass. The same device always lands in the same bucket for a given flag, so raising the percentage only ever adds devices.

Tier limits

Creating a rule beyond your tier’s limit returns 403 Forbidden.

Errors

See also