Update a rule
Every field is optional, and `conditions` and `actions` replace whole.
Runs the real call on your workspace.
PATCH /rules/{id}
Every field is optional, and conditions and actions replace whole.
Example
Needs rules:write. position is accepted here and moves the rule, renumbering whatever it displaces.
curl -X PATCH "$OE/rules/rul_7f3a1c94e05d3862c1f0a44b" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "enabled": false }'{ "object": "rule", "id": "rul_7f3a1c94e05d3862c1f0a44b", "name": "Receipts to their own label", "enabled": false, "position": 0, "matchCount": 148, "updatedAt": "2026-08-30T11:02:19.000Z"}conditions and actions are REPLACE-WHOLE arrays. There is no per-element patch: sending conditions discards the ones that were there and stores exactly what you sent, so read the rule, edit the array, and send it back. A patch that merged would have no way to say "delete the second condition".
The patch is merged onto the stored rule and the WHOLE result is re-validated, never the patch on its own. A PATCH { "actions": [{ "type": "reject" }] } checked in isolation has no conditions to check for an envelope_from and would write exactly the rule that 550s a mailing list.
Disabling is the safe way to stop a rule you are unsure about. It stays in the list, keeps its counts, and is skipped on every message until you turn it back on.
A key limited to particular addresses or domains may patch only a rule that acts on nothing but mail delivered to them, and the patched rule has to stay that way. Patching any other rule it can list, or a patch that would widen one, is a 422 capability_unsupported, and a rule it cannot list is a 404.
An OAuth access token needs a verification code for this call. Until the app has verified one in the last 60 minutes, the call answers 403 step_up_required and changes nothing. An API key is never asked. The Authentication page shows how to ask for a code and verify it.