Create Feature Flag
create_feature_flagCreate a new feature flag. Before writing app code that consumes this, call get_integration_guide with topic=feature-flags and the framework the app uses. The result carries warnings when the flag cannot mean what it looks like — switched on while its onValue is false, or a rule on a plan or role the app does not have. A warning never blocks the write; read it and fix the flag. Every gate in app code is a flag: flags are the standard way to control a route, an API endpoint, a feature or a piece of code. A feature a plan sells is also listed on the plan, and the flag's rule points at bridge:billing.entitlement.. Access by who someone is is a rule on a privilege (preferred) or a role; app code never reads a role, privileges, the plan or a plan feature itself. Numbers are plan quotas, not flags; permission on one specific record stays in app code. Full rule: get_integration_guide topic=fit-together. Arguments: key (required — the identifier code reads, e.g. "beta-ui"), description, state (off | on | on-with-rule; defaults to off), valueType (boolean | string | number | json; defaults to boolean), onValue / offValue (the typed values returned in the on / off states — real JSON values, e.g. true, "variant-b", 42, or an object), and rule for state=on-with-rule. A rule is ordered branches of AND-ed conditions, first match wins, else otherwiseValue; the rule argument has the full shape and examples. A feature a plan sells is listed on the plan (add_plan_feature) and the rule points at that list, never at plan names. For who someone is, prefer a privilege rule over a role rule on the role KEY; read the app's real roles with list_roles first. The same rule gives the same answer in the browser and on the NestJS backend. Use update_feature_flag to change an existing flag, and toggle_feature_flag for a quick on/off switch by key.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | Id of the Bridge app to act on for this call (see list_apps). Omit to use the current app. | |
| key | Yes | Flag KEY the app code reads, e.g. "beta-ui". Lower-case with dashes. | |
| rule | No | Structured targeting rule: { branches: [{ conditions: [{ attribute, operator, values }], returnValue }], otherwiseValue, rolloutPct?, groupRef? }. Branches are first-match-wins; conditions in a branch are AND-ed. A feature a plan sells is listed on the plan (add_plan_feature) and the rule points at that list, never at plan names: { "branches": [{ "conditions": [{ "attribute": "bridge:billing.entitlement.analytics", "operator": "eq", "values": [true] }], "returnValue": true }], "otherwiseValue": false }. For who someone is, prefer a privilege rule ({ "attribute": "privileges", "operator": "contains", "values": ["REPORTS_VIEW"] }, which matches that whole key) over a role rule on the role KEY ("user.role" eq "ADMIN"); read the app's real roles with list_roles first. The same rule gives the same answer in the browser and on the NestJS backend. | |
| state | No | Three-state model: off (always offValue), on (always onValue), on-with-rule (evaluate rule). | |
| onValue | No | Value returned when state=on (typed per valueType). | |
| offValue | No | Value returned when state=off (typed per valueType). | |
| valueType | No | Type of the values this flag returns. | |
| description | No | What the flag controls, for the people who manage it. |