---
title: "Update a rule"
description: "Every field is optional, and `conditions` and `actions` replace whole."
url: "https://openemail.uk/docs/api/rules/update"
area: "API"
category: "Mailbox"
---

# Update a rule

Every field is optional, and `conditions` and `actions` replace whole.

`PATCH /rules/{id}`

## 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**

```
curl -X PATCH "$OE/rules/rul_7f3a1c94e05d3862c1f0a44b" -H "$AUTH" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": false }'
```

**Response**

```
{
  "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.
