Update Policy Rule

Edit a rule's fields. Updates require the whole-feature traffic_policies entitlement (403 without it) but do not re-check the per-rule-type plan gating — admins on a downgraded plan can keep editing rules of types they no longer have access to (but can't add new ones via create).

Every field is optional and applied only when present (a partial patch): name, expression, config, priority, enabled, and also phase and rule_type — both are mutable on update (when you send them they replace the stored value). The resulting config is re-validated against the (possibly new) rule type's schema and re-run through the AI safety check before persistence.

Path parameters

Deprecated: legacy integer ids are still accepted in the path until the sunset, answered with Deprecation and Sunset headers. Use the uuids.

Request body

Same fields as create — all optional. Any of name, expression, config, priority, enabled, phase, rule_type that you send is applied; omitted fields keep their stored value. Strict decoding rejects unknown fields. A config you send replaces the whole stored config, so send every field you keep.

A verify-webhook or jwt-validation rule's config.secret (reads answer it as "****"):

• **** keeps the secret saved on the rule, as long as the rule keeps its rule_type and has a secret. Any other **** is refused with 400 on config.secret (see Errors).
• "", or no secret key, removes it: for a jwt-validation rule on an RS*/ES* algorithm, which checks tokens with its jwks_url. A verify-webhook rule requires a secret, so "" is refused (secret is required).
• Any other value replaces it.

A config left out keeps the whole stored config, secret included (e.g. {"enabled": false}).

Response (200 OK)

The updated rule (with uuid and policy_uuid). A saved secret answers "secret": "****".

Deprecated: until the sunset this response also carries the legacy integer id and *_id fields. Don't use them; read uuid and the *_uuid fields.

Errors