---
title: "openemail.rules"
description: "Every method in this namespace: its signature, its parameters, what it returns and an example."
url: "https://openemail.uk/docs/sdk/reference/rules"
area: "SDK"
category: "Reference"
---

# openemail.rules

Every method in this namespace: its signature, its parameters, what it returns and an example.

## Methods

Conditions and actions evaluated on arriving mail, with dry runs and an audit trail.

### `rules.list()`

List mail rules in evaluation order

```ts
list(options?: RuleListOptions): Promise<Page<RuleResource>>
```

Returns one page of the mailbox's rules in the order they run on arriving mail: ascending `position`, then `createdAt`, then `id`. This is deliberately not newest first. With `stopProcessing` in play, the same rules in a different order file mail differently, so the order you read is the order that matters.

Paging is keyset on that same `(position, createdAt, id)` tuple, and the cursor is opaque: it holds where the last rule on the page sat in that order. Pass `nextCursor` back as `options.cursor` while `hasMore` is true, or let `listAll` or `iterate` walk the pages. `options.enabled` narrows to enabled or disabled rules, and the SDK sends it as the literal word `true` or `false`.

Scopes: `rules:read`.

**Parameters**

- `options.enabled` (`boolean`): Restricts the page to enabled (`true`) or disabled (`false`) rules. Omit it for both.
- `options.limit` (`number`): Rows per page, a whole number from 1 to 100. The server defaults to 25.
- `options.cursor` (`string`): The `nextCursor` from the previous page. Never build one yourself.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`Page<RuleResource>` with `items`, `hasMore` and `nextCursor`. Each rule has `id`, `name`, `description`, `enabled`, `position`, `match`, `conditions`, `actions`, `stopProcessing`, `lastMatchedAt`, `matchCount`, `createdAt` and `updatedAt`.

**Example**

```ts
const page = await openemail.rules.list({ enabled: true, limit: 100 })

for (const rule of page.items) {
    console.log(rule.position, rule.name, rule.matchCount, rule.stopProcessing)
}
```

**Notes**

- A rule deleted, moved or renamed between pages never breaks the walk: the next page starts at the first rule that sorts after the cursor. A cursor this list did not hand out is a 400 `invalid_cursor`.
- A key limited to particular addresses or domains lists only the rules that can act on mail delivered to them: every rule without a `delivered_to` condition, and a rule with one when it can match an address the key holds.
- A mailbox holds at most 100 rules, so `limit: 100` always returns them in a single page.
- A `matchCount` still at zero after weeks is the cheap sign that a rule's conditions never hold. `listRuns` has the detail.

Also available in: API [`GET /rules`](https://openemail.uk/docs/api/reference/rules#get-rules); CLI [`openemail rules list`](https://openemail.uk/docs/cli/reference/rules#rules-list).

### `rules.listAll()`

Collect every rule into one array

```ts
listAll(options?: RuleListOptions): Promise<Array<RuleResource>>
```

Walks every page of the rule list and resolves with all rules in evaluation order, which is the order to read them in when reasoning about what happens to a message. A mailbox holds at most 100 rules, so passing `limit: 100` fetches them in a single request, while the server default of 25 takes up to four.

`options.enabled` collects only enabled or only disabled rules. A disabled rule keeps its position, so a filtered array hides rules that still sit between the ones you see, and `reorder` needs every id. Collect without the filter whenever you intend to change the order.

Scopes: `rules:read`.

**Parameters**

- `options.enabled` (`boolean`): Collects only enabled (`true`) or disabled (`false`) rules.
- `options.limit` (`number`): Page size for each request, 1 to 100. The server defaults to 25.
- `options.cursor` (`string`): Starts the walk from this cursor instead of the first page.
- `options.signal` (`AbortSignal`): Cancels the request in flight and the walk with it.
- `options.apiKey` (`string`): Overrides the client API key for every page of this walk.

**Returns**

`Array<RuleResource>` holding every matching rule, sorted by `position`, then `createdAt`, then `id`.

**Example**

```ts
const rules = await openemail.rules.listAll({ limit: 100 })

const stoppers = rules.filter((rule) => rule.enabled && rule.stopProcessing)

console.log(stoppers.map((rule) => `${rule.position}: ${rule.name}`))
```

**Notes**

- If any page fails the promise rejects and the rules already fetched are discarded.
- Positions are not contiguous. Deleting a rule leaves a gap, and `update` with `position` can make two rules share a number.

Also available in: API [`GET /rules`](https://openemail.uk/docs/api/reference/rules#get-rules).

### `rules.iterate()`

Stream rules one at a time in evaluation order

```ts
iterate(options?: RuleListOptions): AsyncGenerator<RuleResource, void, undefined>
```

Returns an async generator that yields rules in the order arriving mail meets them and fetches the next page only when the current one is drained. Nothing is requested until you consume it, and breaking out of the loop stops further requests.

The walk ends when `hasMore` is false, when a page comes back empty, or when the server repeats a cursor. The cursor points into the `(position, createdAt, id)` order, so moving rules while you iterate can skip or repeat some of them. Finish reading before you call `reorder` or `update` with a `position`.

Scopes: `rules:read`.

**Parameters**

- `options.enabled` (`boolean`): Yields only enabled (`true`) or disabled (`false`) rules.
- `options.limit` (`number`): Page size per request, 1 to 100. The server defaults to 25.
- `options.cursor` (`string`): Starts the walk from this cursor instead of the first page.
- `options.signal` (`AbortSignal`): Cancels the request in flight and ends the iteration.
- `options.apiKey` (`string`): Overrides the client API key for every page of this walk.

**Returns**

`AsyncGenerator<RuleResource, void, undefined>` yielding one rule per step.

**Example**

```ts
for await (const rule of openemail.rules.iterate({ enabled: true })) {
    if (rule.stopProcessing) {
        console.log(`Mail matching "${rule.name}" skips every rule after position ${rule.position}`)
        break
    }
}
```

**Notes**

- An aborted `options.signal` rejects the pending page request, which throws out of the `for await` loop.

Also available in: API [`GET /rules`](https://openemail.uk/docs/api/reference/rules#get-rules).

### `rules.get()`

Read one mail rule

```ts
get(id: string, options?: RequestScope): Promise<RuleResource>
```

Fetches a single rule by its `rul_` id. Rules have no slug and the name is editable, so store the id if your code needs to find the rule again.

The stored `conditions` are normalised, so `negate` is always present and false unless you set it. `lastMatchedAt` and `matchCount` move each time the rule fires on an arriving message, which makes them the quickest way to see whether a rule is doing anything without reading `listRuns`.

Scopes: `rules:read`.

**Parameters**

- `id` (`string`, required): The rule's `rul_` id.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`RuleResource` with `id`, `name`, `description`, `enabled`, `position`, `match`, `conditions`, `actions`, `stopProcessing`, `lastMatchedAt`, `matchCount`, `createdAt` and `updatedAt`.

**Example**

```ts
const rule = await openemail.rules.get('rul_4f1c9a2b7d3e8f6a0b5c1d2e')

console.log(rule.enabled, rule.match, rule.conditions.length)
console.log(rule.matchCount, rule.lastMatchedAt)
```

**Notes**

- A missing rule is a 404 `resource_not_found`, whether it was deleted or belongs to another workspace. A key limited to particular addresses or domains gets the same 404 for a rule that cannot act on mail delivered to them.
- `matchCount` counts messages the rule matched, not actions it carried out. A match whose actions were all refused still counts.

Also available in: API [`GET /rules/{id}`](https://openemail.uk/docs/api/reference/rules#get-rules-id); CLI [`openemail rules get`](https://openemail.uk/docs/cli/reference/rules#rules-get).

### `rules.create()`

Create a mail rule at the end of the order

```ts
create(body: RuleCreate, options?: RequestScope): Promise<RuleResource>
```

Creates a rule that runs on mail arriving in the mailbox, with no API call involved once it exists. It is appended after every existing rule and is enabled unless you pass `enabled: false`. There is no `position` on create: move the rule afterwards with `reorder`, the only call that guarantees an exact sequence. Creating it disabled and calling `test` first is the safe order.

Conditions are a flat list. `match: 'all'` is AND, `match: 'any'` is OR, and `negate: true` inverts a single condition, so `(A and B) or C` takes two rules. `value` is always a string. `has_attachment` and `spam` take only `equals` with `'true'` or `'false'`. `attachment_size`, `message_size`, `hour` and `weekday` take a number with `gt`, `lt` or `equals`, and `gt` or `lt` on any other field is refused. Text comparisons ignore case, and `matches` is a whole value glob over `*` and `?` that needs at least two letters or digits. A `header` condition must name the header it reads in `header`.

Actions apply in order. `label` and `remove_label` take a label id, `forward` takes an email address and `reply` takes a template id or slug. A forward is only delivered once the destination has confirmed it accepts mail forwarded from your domain, and a reply goes to each sender at most once per 24 hours and never to bounces, auto-responders or mailing lists. A rule with `reject` must also test `envelope_from`, otherwise it is a 422 `reject_needs_envelope`, because refusing mail on the strength of a `From` header bounces the mailing list rather than the author.

Scopes: `rules:write`.

**Parameters**

- `body.name` (`string`, required): Display name, 1 to 100 characters after trimming and unique per mailbox.
- `body.description` (`string | null`): Free text note, at most 500 characters.
- `body.enabled` (`boolean`): Whether the rule runs on arriving mail. Defaults to true.
- `body.match` (`'all' | 'any'`): Whether every condition or any single one must hold. Defaults to `all`.
- `body.conditions` (`Array<RuleConditionInput>`, required): 1 to 20 conditions, each `{ field, op, value }` with optional `header` (at most 128 characters) and `negate`. `value` is at most 512 characters.
- `body.actions` (`Array<RuleAction>`, required): 1 to 10 actions, each `{ type, value }`, with `value` at most 320 characters.
- `body.stopProcessing` (`boolean`): When true, no later rule runs on a message this rule matched. Defaults to false.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`RuleResource` with the new `id`, the `position` it was appended at, `matchCount` of 0 and `lastMatchedAt` of null.

**Example**

```ts
const labels = await openemail.labels.listAll()
const receipts = labels.find((label) => label.name === 'Receipts')

const rule = await openemail.rules.create({
    name: 'Receipts to their own label',
    enabled: false,
    conditions: [
        { field: 'from_domain', op: 'equals', value: 'stripe.com' },
        { field: 'subject', op: 'contains', value: 'receipt' }
    ],
    actions: [
        { type: 'label', value: receipts.id },
        { type: 'archive' }
    ],
    stopProcessing: true
})

console.log(rule.id, rule.position)
```

**Notes**

- Validation failures are a 422 `invalid_rule` whose `param` names the path, such as `conditions.0.op`. A duplicate name is a 409 `rule_name_taken`.
- A mailbox holds at most 100 rules, and the next create is a 422 `rule_limit_reached`.
- `from_domain` also matches subdomains, so `equals` with `stripe.com` holds for mail from `mail.stripe.com`. `hour` and `weekday` are read in UTC, with `weekday` 0 for Sunday.
- Not retried by the SDK and there is no idempotency key, so repeating a create after a lost response makes a second rule unless the name collides.
- A key limited to particular addresses or domains creates only a rule that acts on nothing but mail delivered to them, so it needs a `delivered_to` condition no other address in the workspace matches, such as `equals` with one of its addresses. Anything else is a 422 `capability_unsupported` on `conditions`.

Also available in: API [`POST /rules`](https://openemail.uk/docs/api/reference/rules#post-rules); CLI [`openemail rules create`](https://openemail.uk/docs/cli/reference/rules#rules-create).

### `rules.update()`

Change a rule, replacing conditions or actions whole

```ts
update(id: string, patch: RulePatch, options?: RequestScope): Promise<RuleResource>
```

Merges the patch onto the stored rule and validates the whole result, so an omitted field keeps its stored value instead of collecting a default. A patch that only renames a rule cannot switch a disabled one back on, and a patch that adds a `reject` action is checked against the conditions already stored.

`conditions` and `actions` replace the entire array. There is no way to add or remove a single element: read the rule, change the array, and send all of it. `match` and `stopProcessing` read across the whole set, which is why element level edits are not offered.

`position` moves this one rule without renumbering the others. Positions are not unique and ties break by `createdAt` then `id`, so landing on an occupied position puts the older rule first. Use `reorder` when the exact sequence matters. Setting `enabled: false` is the reversible alternative to `delete`, and a disabled rule keeps its place in the order.

Scopes: `rules:write`.

**Parameters**

- `id` (`string`, required): The rule's `rul_` id.
- `patch.name` (`string`): Replacement name, 1 to 100 characters and unique per mailbox.
- `patch.description` (`string | null`): Replacement note of at most 500 characters, or null to clear it.
- `patch.enabled` (`boolean`): Turns the rule on or off without moving it.
- `patch.match` (`'all' | 'any'`): Whether every condition or any single one must hold.
- `patch.conditions` (`Array<RuleConditionInput>`): Complete replacement list of 1 to 20 conditions.
- `patch.actions` (`Array<RuleAction>`): Complete replacement list of 1 to 10 actions.
- `patch.stopProcessing` (`boolean`): When true, no later rule runs on a message this rule matched.
- `patch.position` (`number`): New position, a whole number from 0 to 1,000,000. Other rules keep theirs.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`RuleResource` as saved, with a fresh `updatedAt`. `matchCount` and `lastMatchedAt` are untouched by an edit.

**Example**

```ts
const rule = await openemail.rules.get('rul_4f1c9a2b7d3e8f6a0b5c1d2e')

const updated = await openemail.rules.update(rule.id, {
    conditions: [
        ...rule.conditions,
        { field: 'has_attachment', op: 'equals', value: 'true' }
    ],
    enabled: true
})

console.log(updated.conditions.length, updated.enabled)
```

**Notes**

- Validation failures are a 422 `invalid_rule` or `reject_needs_envelope` with `param` naming the path, such as `conditions.1.value`.
- Renaming onto another rule's name is a 409 `rule_name_taken`.
- Not retried by the SDK, since there is no idempotency key on this resource.
- 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. Anything else is a 422 `capability_unsupported`, and a rule the key cannot list is a 404.

Also available in: API [`PATCH /rules/{id}`](https://openemail.uk/docs/api/reference/rules#patch-rules-id); CLI [`openemail rules update`](https://openemail.uk/docs/cli/reference/rules#rules-update).

### `rules.delete()`

Delete a mail rule

```ts
delete(id: string, options?: RequestScope): Promise<DeletedRuleResource>
```

Permanently removes a rule. There is no undo, and mail it already filed stays where it put it. If you might want the rule back, `update(id, { enabled: false })` switches it off and keeps its place in the order.

The run history survives. `listRuns({ ruleId })` still returns what the rule did, under the name it had at the time. The other rules are not renumbered, so a gap in `position` is normal afterwards.

Scopes: `rules:write`.

**Parameters**

- `id` (`string`, required): The rule's `rul_` id.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`DeletedRuleResource`: `{ object: 'rule', id, deleted: true }`.

**Example**

```ts
const deleted = await openemail.rules.delete('rul_4f1c9a2b7d3e8f6a0b5c1d2e')

console.log(deleted.id, deleted.deleted)
```

**Notes**

- Deleting frees the name, so a new rule can take it straight away.
- Not retried by the SDK. Repeating a delete that already succeeded is a 404 about something that worked.
- A key limited to particular addresses or domains deletes only a rule that acts on nothing but mail delivered to them. Another rule it can list is a 422 `capability_unsupported`, and one it cannot list is a 404.

Also available in: API [`DELETE /rules/{id}`](https://openemail.uk/docs/api/reference/rules#delete-rules-id); CLI [`openemail rules delete`](https://openemail.uk/docs/cli/reference/rules#rules-delete).

### `rules.reorder()`

Set the evaluation order of every rule

```ts
reorder(ruleIds: Array<string>, options?: RequestScope): Promise<Array<RuleResource>>
```

Replaces the whole order in one transaction. `ruleIds` must name every rule on the mailbox exactly once, and each rule's `position` becomes its index in the array, starting at 0. Either the whole order lands or nothing moves.

A list that leaves a rule out or names one twice is a 422 `incomplete_order`, because an omitted rule would have to go somewhere and there is no right answer for where. Build the list from `listAll()` without the `enabled` filter so disabled rules are included. The new order applies to the next message that arrives, and mail already filed is not revisited.

Scopes: `rules:write`.

**Parameters**

- `ruleIds` (`Array<string>`, required): Every rule id on the mailbox in the order they should run, 1 to 100 entries.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`Array<RuleResource>` holding every rule on the mailbox, sorted by its new `position`. The SDK unwraps the list envelope, so this is a plain array rather than a page.

**Example**

```ts
const rules = await openemail.rules.listAll({ limit: 100 })
const spam = rules.find((rule) => rule.name === 'Refuse known spammers')

if (spam) {
    const rest = rules.filter((rule) => rule.id !== spam.id).map((rule) => rule.id)
    const ordered = await openemail.rules.reorder([spam.id, ...rest])

    console.log(ordered.map((rule) => `${rule.position} ${rule.name}`))
}
```

**Notes**

- An id that is not on this mailbox is a 404 `resource_not_found`, and nothing moves.
- The SDK retries this call on network errors and retryable statuses, since applying the same order twice lands in the same place.
- A mailbox with no rules cannot call this: an empty `ruleIds` is a 422 `invalid_parameter`.
- A key limited to particular addresses or domains names every rule `list` returns for it and nothing else. It may move only the rules that act on nothing but mail delivered to its addresses, anywhere among the others; moving any other rule is a 422 `capability_unsupported`. The rules it cannot list keep their places, and the result lists only the rules it can see.

Also available in: API [`POST /rules/reorder`](https://openemail.uk/docs/api/reference/rules#post-rules-reorder); CLI [`openemail rules reorder`](https://openemail.uk/docs/cli/reference/rules#rules-reorder).

### `rules.test()`

Dry run a rule against mail already in the mailbox

```ts
test(id: string, body?: RuleTestInput, options?: RequestScope): Promise<RuleTestResource>
```

Evaluates one rule against stored mail with the same matcher delivery uses and reports what it would have caught and what it would do. It changes nothing, sends nothing and files nothing, which is why it needs only `rules:read`. It works on a disabled rule, so the intended sequence is create with `enabled: false`, test, then enable.

By default it reads up to 50 inbox threads from the last 30 days. For each thread it tests the newest message the mailbox received rather than sent, and threads that fail to load or hold only your own messages are skipped, so `scanned` can come in below `limit`. Pass `threadIds` to test specific threads from any folder instead, and `days` and `limit` are then ignored. A message an existing rule already moved out of the inbox is not in the default sample, and `listRuns` is the record of what really happened.

Read `warnings` before `matched`. `field_unevaluable` means a condition reads something stored mail no longer carries (`envelope_from`, `header`, `list_id`, `delivered_to` or `message_size`), so it never held here, and under `negate` it holds on everything. `field_approximate` flags attachment, `hour` and `weekday` conditions answered from stored data that can differ from delivery. `body_encrypted` means a `body` condition met mail whose body is sealed. `forward_loop` means a forward target leads back to this mailbox, and `forward_unverified` means the target is not hosted here, so the forwarded copy is rebuilt and loses its original DKIM signature.

Scopes: `rules:read`.

**Parameters**

- `id` (`string`, required): The rule's `rul_` id. Disabled rules can be tested.
- `body.threadIds` (`Array<string>`): Up to 50 specific thread ids to test instead of the recent window. Ids that fail to load are skipped.
- `body.days` (`number`): How far back the default window reaches, 1 to 365. Defaults to 30.
- `body.limit` (`number`): How many recent inbox threads to read, 1 to 200. Defaults to 50.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`RuleTestResource` with `ruleId`, `scanned`, `matched`, `wouldApply` (the actions as `type` or `type:value`), `messages` (each `{ threadId, from, subject, receivedAt }`) and `warnings` (each `{ code, value }`, where `value` is the field name or the forward address).

**Example**

```ts
const dry = await openemail.rules.test('rul_4f1c9a2b7d3e8f6a0b5c1d2e', { days: 30, limit: 100 })

console.log(dry.scanned, dry.matched, dry.wouldApply)
console.log(dry.messages.map((message) => message.subject))

if (dry.warnings.length === 0 && dry.matched > 0) {
    await openemail.rules.update(dry.ruleId, { enabled: true })
}
```

**Notes**

- There is no call that applies a rule to mail already in the mailbox. Rules only act on mail that arrives while they are enabled.
- `wouldApply` lists what the rule declares. At delivery a forward to an unconfirmed address or a suppressed reply still fails, and only `listRuns` shows that.
- The SDK retries it on network errors and retryable statuses, because a dry run has no side effects.
- A key limited to particular addresses or domains tests only a rule it can list, against conversations delivered to its addresses. `threadIds` naming any other conversation are skipped, and a rule it cannot list is a 404.

Also available in: API [`POST /rules/{id}/test`](https://openemail.uk/docs/api/reference/rules#post-rules-id-test); CLI [`openemail rules test`](https://openemail.uk/docs/cli/reference/rules#rules-test).

### `rules.listRuns()`

List what rules actually did to arriving mail

```ts
listRuns(options?: RuleRunListOptions): Promise<Page<RuleRunResource>>
```

Returns one page of the rule audit log, newest first. Each row is one rule matching one arriving message, with the actions that took effect and the ones that were refused.

Each row copies the rule's name at the moment it fired, so renamed and deleted rules still read correctly, and `options.ruleId` works for a rule that no longer exists. `options.threadId` answers the other common question: why a particular message ended up where it did.

`actions` lists the action types that were applied, and `failures` lists refusals as `type: reason`. A non empty `failures` means the rule matched but the mailbox declined part of it, for example a `reply` suppressed because that sender was already answered in the last day, a `forward` to an address that has not confirmed, or a `reject` that could not be refused at SMTP and was filed as spam instead.

Scopes: `rules:read`.

**Parameters**

- `options.ruleId` (`string`): Only runs of this rule, including a rule that has since been deleted.
- `options.threadId` (`string`): Only runs recorded against this thread.
- `options.limit` (`number`): Rows per page, a whole number from 1 to 100. The server defaults to 25.
- `options.cursor` (`string`): The `nextCursor` from the previous page. Never build one yourself.
- `options.signal` (`AbortSignal`): Cancels the request.
- `options.apiKey` (`string`): Overrides the client API key for this call only.

**Returns**

`Page<RuleRunResource>` with `items`, `hasMore` and `nextCursor`. Each run has `id`, `ruleId`, `ruleName`, `threadId`, `messageId`, `sender`, `subject`, `actions`, `failures` and `createdAt`.

**Example**

```ts
const page = await openemail.rules.listRuns({ ruleId: 'rul_4f1c9a2b7d3e8f6a0b5c1d2e', limit: 50 })

for (const run of page.items) {
    console.log(run.createdAt, run.sender, run.actions, run.failures)
}
```

**Notes**

- `actions` holds bare types such as `label` or `archive`, without the label id or address the rule was configured with. Read the rule itself for those.
- `sender` is lower-cased and trimmed, and `subject` is cut at 500 characters.
- A cursor naming a run that never existed is a 400 `invalid_cursor`.
- A key limited to particular addresses or domains reads only the runs of rules it can list, so runs of a rule deleted since, whose conditions are gone, are left out for such a key.
- Only mail arriving while the rule is enabled writes here. `test` and edits never do.

Also available in: API [`GET /rules/runs`](https://openemail.uk/docs/api/reference/rules#get-rules-runs); CLI [`openemail rules list-runs`](https://openemail.uk/docs/cli/reference/rules#rules-list-runs).

### `rules.listAllRuns()`

Collect every matching rule run into one array

```ts
listAllRuns(options?: RuleRunListOptions): Promise<Array<RuleRunResource>>
```

Walks every page of the rule audit log and resolves with all matching runs, newest first. Unlike rules, runs are not capped: a busy rule can leave thousands of rows, so narrow with `options.ruleId` or `options.threadId` before collecting, and prefer `iterateRuns` when you can stop early.

Pages are keyset on `createdAt` and `id`, walking backwards in time. Runs recorded after the walk starts are newer than its first page and are not included.

Scopes: `rules:read`.

**Parameters**

- `options.ruleId` (`string`): Only runs of this rule, including a rule that has since been deleted.
- `options.threadId` (`string`): Only runs recorded against this thread.
- `options.limit` (`number`): Page size for each request, 1 to 100. The server defaults to 25.
- `options.cursor` (`string`): Starts the walk from this cursor instead of the newest run.
- `options.signal` (`AbortSignal`): Cancels the request in flight and the walk with it.
- `options.apiKey` (`string`): Overrides the client API key for every page of this walk.

**Returns**

`Array<RuleRunResource>` holding every matching run, newest first.

**Example**

```ts
const runs = await openemail.rules.listAllRuns({ ruleId: 'rul_4f1c9a2b7d3e8f6a0b5c1d2e', limit: 100 })

const refused = runs.filter((run) => run.failures.length > 0)

console.log(`${refused.length} of ${runs.length} matches were partly refused`)
```

**Notes**

- If any page fails the promise rejects and the runs already fetched are discarded.
- Without a filter this reads the whole mailbox audit, one request per page.

Also available in: API [`GET /rules/runs`](https://openemail.uk/docs/api/reference/rules#get-rules-runs).

### `rules.iterateRuns()`

Stream rule runs one at a time, newest first

```ts
iterateRuns(options?: RuleRunListOptions): AsyncGenerator<RuleRunResource, void, undefined>
```

Returns an async generator over the rule audit log that yields runs individually and fetches the next page only when the current one is drained. Nothing is requested until you consume it, and breaking out of the loop stops further requests, which makes it the right way to find the latest run of some kind without reading the whole history.

The walk ends when `hasMore` is false, when a page comes back empty, or when the server repeats a cursor. Runs recorded after the walk starts are newer than its cursor and are not yielded.

Scopes: `rules:read`.

**Parameters**

- `options.ruleId` (`string`): Only runs of this rule, including a rule that has since been deleted.
- `options.threadId` (`string`): Only runs recorded against this thread.
- `options.limit` (`number`): Page size per request, 1 to 100. The server defaults to 25.
- `options.cursor` (`string`): Starts the walk from this cursor instead of the newest run.
- `options.signal` (`AbortSignal`): Cancels the request in flight and ends the iteration.
- `options.apiKey` (`string`): Overrides the client API key for every page of this walk.

**Returns**

`AsyncGenerator<RuleRunResource, void, undefined>` yielding one run per step.

**Example**

```ts
for await (const run of openemail.rules.iterateRuns({ ruleId: 'rul_4f1c9a2b7d3e8f6a0b5c1d2e' })) {
    if (run.failures.some((failure) => failure.startsWith('forward:'))) {
        console.log(run.createdAt, run.threadId, run.failures)
        break
    }
}
```

**Notes**

- An aborted `options.signal` rejects the pending page request, which throws out of the `for await` loop.

Also available in: API [`GET /rules/runs`](https://openemail.uk/docs/api/reference/rules#get-rules-runs).