Update Feature Flag
update_feature_flagUpdate an existing feature flag by its id (get the id from list_feature_flags). Only the fields you pass are changed. 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. Fields: key, description, state (off | on | on-with-rule), valueType (boolean | string | number | json), onValue / offValue (typed JSON values), rule (replaces the whole rule), clearRule: true to remove the rule entirely. 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. For a plain on/off switch prefer toggle_feature_flag, which works by key.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Flag id from list_feature_flags (this tool addresses flags by id; toggle_feature_flag takes the key). | |
| app | No | Id of the Bridge app to act on for this call (see list_apps). Omit to use the current app. | |
| key | No | New flag key. Changing it breaks app code that reads the old key. | |
| 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). | |
| clearRule | No | true removes the existing rule (sets it to null). | |
| valueType | No | Type of the values this flag returns. | |
| description | No | New description. |