ドキュメント本文へスキップ
API

ルールを一覧する

接続上のすべてのルールを、評価される順序で返します。

GETapi.openemail.uk/rules

実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。

GET /rules

接続上のすべてのルールを、評価される順序で返します。

ルールが走るしくみ

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

ルールは、届いたメッセージに対する条件の一覧と、それに一致したものに対して取るアクションの一覧です。ルールは書いた人ではなく「接続」に属します。ワークスペースのキーは同僚と同じルールを見ますし、作成者のアカウントを削除してもルールが道連れになることはありません。

1 つの接続は 100 個のルールを持ち、各ルールは最大 20 個の条件と 10 個のアクションを持ちます。これらはプランの制限ではなく暴走スクリプトへの備えです。101 個目のルールは rule_limit_reached、422 で、21 個目の条件は何も書き込まれる前にスキーマが拒否します。

match: "all" は条件を AND で、match: "any" は OR で結び、単一の条件に付けた negate が NOT です。ネストしたブール木はありません。(A and B) or C は 2 つのルールになります。これは手抜きではなく決定です。再帰的なスキーマは $refStrategy: "none" では OpenAPI ドキュメントに記述できず、MCP クライアントに JSON Schema として渡すこともできず、このリポジトリで過去に TypeScript のインスタンス化上限を吹き飛ばしたのもまさにその形です。2 つのルールに分けることは、半年後に人が読み返すときの読み方でもあります。

接続上の有効なすべてのルールが、届くすべてのメッセージに対して position の昇順で評価されます。stopProcessing: true を持つルールが一致した時点で評価は止まり、それより下は一切考慮されません。一致した 2 つのルールがどちらもフォルダーを指定している場合は「後の」ほうが勝ち、メッセージはそのフォルダーに入ります。それが番号付きの一覧から自然に読み取れる解釈であり、順序について、発見させるのではなく明記しておく価値のある唯一の点です。

ルールはフェイルオープンします。古いクライアントが書いた条件、パターンにコンパイルできない値、応答しないデータベース。いずれの場合もその処理はスキップされ、メッセージはルールがなかった場合と同じように配信され、失敗はその実行に対して記録されます。例外を投げるルールエンジンは、届かないメッセージを意味します。スキップされるルールエンジンは、フォルダーが 1 つ違うメッセージで済みます。

遡及処理はありません。ルールは、それが存在した後に届くメールに何が起きるかを決めるものであり、既存のメールボックスにルールを適用するエンドポイントは意図的に用意していません。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 は boolean への型強制ではなく文字列の truefalse を取ります。これは細かすぎるのではありません。Boolean("false")true なので、型強制するクエリは「無効なルールを見せて」という要求に有効なルールを返し、しかも正しく動いているように見えてしまいます。

一覧の順序が評価の順序なので、上から下へ読むことがメッセージに何が起きるかを読むことになります。position は一意でも id でもなく(POST /rules/reorder で振り直されます)、ルールを指すときは現在の位置ではなく rul_ の id を使ってください。

matchCountlastMatchedAt は、読み出して書き戻すのではなく、メールが届くたびにデータベース内で加算されるので、同時に届いた 2 通の間でカウントが失われることはありません。一度も発火していないルールは 0null を返します。ルールが動かないと言われたときに、まず見るべき答えです。