ルールを一覧する
接続上のすべてのルールを、評価される順序で返します。
実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。
GET /rules
接続上のすべてのルールを、評価される順序で返します。
ルールが走るしくみ
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 "$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 への型強制ではなく文字列の true と false を取ります。これは細かすぎるのではありません。Boolean("false") は true なので、型強制するクエリは「無効なルールを見せて」という要求に有効なルールを返し、しかも正しく動いているように見えてしまいます。
一覧の順序が評価の順序なので、上から下へ読むことがメッセージに何が起きるかを読むことになります。position は一意でも id でもなく(POST /rules/reorder で振り直されます)、ルールを指すときは現在の位置ではなく rul_ の id を使ってください。
matchCount と lastMatchedAt は、読み出して書き戻すのではなく、メールが届くたびにデータベース内で加算されるので、同時に届いた 2 通の間でカウントが失われることはありません。一度も発火していないルールは 0 と null を返します。ルールが動かないと言われたときに、まず見るべき答えです。