ルールをテストする
このルールが最近のメッセージのどれを捕まえていたかを返します。何も変更しません。
実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。
POST /rules/{id}/test
このルールが最近のメッセージのどれを捕まえていたかを返します。何も変更しません。
例
rules:read が必要です。ドライランはメールボックスを読むだけで何も書かないので、rules:write の操作ではありません。days の既定値は 30 で最大 365、limit の既定値は 50 で最大 200 です。threadIds を指定すると、期間ではなく指定したスレッドをテストします。
curl -X POST "$OE/rules/rul_7f3a1c94e05d3862c1f0a44b/test" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "days": 30, "limit": 50 }'{ "object": "rule_test", "ruleId": "rul_7f3a1c94e05d3862c1f0a44b", "scanned": 50, "matched": 3, "wouldApply": ["label:USER_RECEIPTS", "archive"], "messages": [ { "threadId": "thr_5d31c2a8…", "from": "[email protected]", "subject": "Your receipt", "receivedAt": "2026-08-28T10:00:00.000Z" } ], "warnings": [{ "code": "forward_unverified", "value": "[email protected]" }]}配信パス上で動くのと同じエンジンがこれに答えます。データベースにもネットワークにも触れない、意図的に純粋な 1 つのモジュールなので、設定画面、ドライラン、SMTP ハンドラーがルールの一致について食い違うことはありえません。二度書かれたプレビューは 1 つの問いに対する 2 つの答えであり、人に見せられるのは誤ったほうです。
構造上の上限があります。最大 1 年分、最大 200 通です。これは実時間の予算を持つ Worker の中で走るので、無制限のスキャンは、途中で死んで何も返さないリクエストになります。
無効なルールもテストできます。それが狙いです。書いて、テストして、それから有効にしてください。
warnings には、構文は通るが期待どおりに動かないルールが現れます。実際に出会うのは、誰も確認していない転送先アドレスでしょう。警告がテストを止めることはありません。ドライランの目的は、最初の問題で失敗することではなく、見つかったものを 1 回の実行ですべて報告することです。
「これをメールボックス全体に実行する」はない
POST /rules/{id}/run は意図的に存在せず、今後も作りません。メールボックス全体にルールを遡って適用することは、範囲が無制限で、取り消せず、やり直しもできません（10 年分のメールに対する trash アクションは、二度目のない 1 回の呼び出しです）。さらに、そのために使う書き込みパスは保存済みのスレッドにマージするので、整理のつもりが、触れたすべてのメッセージを受信トレイの先頭に押し上げる副作用を生みます。
このエンドポイントは、その要求の正直な半分です。実際の問いである「これは何をしていたか」に答え、そのうえで、本当に振り分けたいメッセージは PATCH /threads/{id} で処理します。