Update Firewall Policy

Edit the policy: name, description, action, priority, enabled flag — and, with conditions, replace its conditions in the same transaction. Without conditions this call doesn't touch them; single conditions are also managed via the /policies/{uuid}/conditions endpoints.

Changes take effect on the next request — no caching window. Toggling enabled is the right knob for staged rollouts: configure conditions, verify on a non-production endpoint, then flip true.

Path parameters

Request body

Same fields as create: name, description, action, priority, enabled, conditions. Pass any subset; omitted fields keep their existing value. (A non-empty name, a non-nil description, an action of allow/block/challenge, a non-negative priority, or an enabled flag each overwrite the current value when present.)

conditions (array of {type, operator, value, logical_operator?}, as in Add Firewall Condition) replaces all the policy's conditions, in that order, in the same transaction as the other fields. All are validated first; if one is refused nothing changes — the old conditions stay. [] removes every condition (the policy then matches every request); omit the field (or send null) to keep them.

Response (200 OK)

The updated policy, in the list-entry shape (id, uuid, user_uuid, account_uuid, name, description, action, priority, enabled, created_at, updated_at), with its conditions in full (omitted when it has none). Its match statistics are the ones its list row shows, over the same 7-day window: hit_count, and last_matched / hits_daily (both omitted when the policy hasn't matched in the window). Best-effort, as on the list.

Deprecated: until the sunset this response also carries the legacy integer user_id and account_id fields. Don't use them; read user_uuid and account_uuid.

Errors