Перейти к документации
API

Список правил

Все правила подключения в том порядке, в котором они вычисляются.

GETapi.openemail.uk/rules

Выполняет настоящий запрос в вашем рабочем пространстве, с вашим собственным ключом.

GET /rules

Все правила подключения в том порядке, в котором они вычисляются.

Как работает правило

shell
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"

Правило — это список условий для приходящего сообщения и список действий над всем, что им соответствует. Правила принадлежат ПОДКЛЮЧЕНИЮ, а не тому, кто их написал. Ключ рабочего пространства видит те же правила, что и коллега, а удаление аккаунта автора не уносит их с собой.

Подключение содержит 100 правил, и каждое из них — не более 20 условий и 10 действий. Это защита от сорвавшегося скрипта, а не тарифные лимиты: 101-е правило — это rule_limit_reached, 422, а 21-е условие отклоняется схемой ещё до того, как что-либо будет записано.

match: "all" объединяет условия по И, match: "any" — по ИЛИ, а negate на отдельном условии — это НЕ. Вложенного логического дерева нет: (A и B) или C — это два правила. Это решение, а не срезанный угол. Рекурсивную схему нельзя описать в документе OpenAPI с $refStrategy: "none", нельзя передать клиенту MCP как JSON Schema, и это ровно та форма, которая в этом репозитории уже пробивала потолок инстанцирования TypeScript. Два правила — это ещё и то, как человек прочитает это полгода спустя.

Каждое включённое правило подключения вычисляется для каждого приходящего сообщения в порядке position, начиная с наименьшего. Вычисление останавливается после совпавшего правила с stopProcessing: true, и всё, что ниже него, не рассматривается вовсе. Если два совпавших правила называют папку, побеждает ПОЗДНЕЕ, и сообщение оказывается в его папке, — именно так читается нумерованный список, и это единственное, что про порядок стоит сказать прямо, а не оставить на самостоятельное открытие.

Правила отказывают ОТКРЫТО. Условие, написанное более старым клиентом, значение, которое не компилируется в шаблон, база данных, которая не отвечает, — каждое из этого пропускается, и сообщение доставляется так, как доставилось бы и без правил, а сбой записывается в журнал запуска. Движок правил, который бросает исключение, — это сообщение, которое никогда не дойдёт; пропущенный движок правил — это одно сообщение не в той папке.

Ничто не действует задним числом. Правило решает, что произойдёт с почтой, пришедшей после его появления, и эндпоинта, применяющего правило к уже имеющемуся ящику, намеренно нет. См. POST /rules/{id}/test, который отвечает на вопрос, который люди на самом деле задают, когда тянутся за этим.

Пример

Требует rules:read. limit доходит до 100, cursor непрозрачен (передавайте обратно полученный nextCursor), а enabled сужает выборку до одной стороны переключателя.

curl
curl "$OE/rules?limit=25&enabled=true" -H "$AUTH"
Ответ
{  "object": "list",  "data": [    {      "object": "rule",      "id": "rul_7f3a1c94e05d3862c1f0a44b",      "name": "Receipts to their own label",      "description": null,      "enabled": true,      "position": 0,      "match": "all",      "conditions": [        { "field": "from_domain", "op": "matches", "value": "*.stripe.com", "negate": false },        { "field": "subject", "op": "contains", "value": "receipt", "negate": false }      ],      "actions": [        { "type": "label", "value": "USER_RECEIPTS" },        { "type": "archive" }      ],      "stopProcessing": true,      "lastMatchedAt": "2026-08-29T11:04:12.000Z",      "matchCount": 148,      "createdAt": "2026-08-01T09:00:00.000Z",      "updatedAt": "2026-08-20T16:31:00.000Z"    }  ],  "hasMore": false,  "nextCursor": null}

enabled принимает строки true и false, а не приведённое булево значение, и это не придирчивость: Boolean("false") — это true, так что приведённый параметр ответил бы на «покажи мои отключённые правила» включёнными и выглядел бы работающим.

Порядок списка — это порядок вычисления, поэтому чтение сверху вниз — это чтение того, что произойдёт с сообщением. position не уникально и не является идентификатором (его перенумеровывает POST /rules/reorder), так что опирайтесь на идентификатор rul_ правила, а не на то, где оно сейчас стоит.

matchCount и lastMatchedAt считаются в базе данных по мере прихода почты, а не читаются и переписываются, поэтому два сообщения, пришедшие одновременно, не могут потерять счёт между собой. Никогда не срабатывавшее правило показывает 0 и null, и именно этот ответ важен, когда кто-то говорит, что правило не работает.