नियम जाँचें
आपके हाल के किन संदेशों को यह नियम पकड़ता। यह कुछ नहीं बदलता।
असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।
POST /rules/{id}/test
आपके हाल के किन संदेशों को यह नियम पकड़ता। यह कुछ नहीं बदलता।
उदाहरण
rules:read चाहिए। dry run मेलबॉक्स पढ़ता है और कुछ लिखता नहीं, इसलिए यह 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]" }]}इसका जवाब वही इंजन देता है जो डिलीवरी पथ पर चलता है। यह एक ही मॉड्यूल है, जानबूझकर शुद्ध (कोई डेटाबेस नहीं, कोई नेटवर्क नहीं), ताकि सेटिंग्स स्क्रीन, dry run और SMTP हैंडलर इस बात पर असहमत न हो सकें कि नियम मेल खाता है या नहीं। दो बार लिखा गया प्रीव्यू एक सवाल के दो जवाब है, और जो किसी व्यक्ति को दिखाया जाता है वही गलत निकलता है।
संरचना से ही सीमित: अधिकतम एक साल में अधिकतम 200 संदेश। यह एक Worker के भीतर चलता है जिसका घड़ी-समय बजट है, और असीमित स्कैन ऐसा अनुरोध है जो आधे रास्ते मर जाता है और दिखाने को कुछ नहीं छोड़ता।
अक्षम नियम भी जाँचा जा सकता है। यही तो बात है: उसे लिखें, जाँचें, फिर सक्षम करें।
warnings वहाँ है जहाँ ऐसा नियम सामने आता है जो parse तो होता है पर सही व्यवहार नहीं करेगा। जिस forward पते की किसी ने पुष्टि नहीं की, वही आपको सबसे ज़्यादा मिलेगा। चेतावनी कभी test रोकती नहीं: dry run का मतलब ही यह है कि पहली दिक्कत पर विफल होने के बजाय एक ही बार में सब कुछ बता दे।
“इसे मेरे पूरे मेलबॉक्स पर चलाओ” जैसा कुछ नहीं है
जानबूझकर कोई POST /rules/{id}/run नहीं है, और न होगा। पूरे मेलबॉक्स पर नियम को पूर्वव्यापी रूप से लागू करना असीमित, अपरिवर्तनीय और बिना undo के है (दस साल की मेल पर trash कार्रवाई एक ही कॉल है और दूसरा मौका नहीं), और जिस write पथ का उसे इस्तेमाल करना पड़ता वह संग्रहित थ्रेड में merge होता है — जिससे सफ़ाई के दुष्प्रभाव के रूप में हर छुआ गया संदेश इनबॉक्स के ऊपर आ जाता।
यह एंडपॉइंट उस अनुरोध का ईमानदार आधा हिस्सा है: यह "यह क्या करता" का जवाब देता है, जो असली सवाल है, और फिर आप जिन संदेशों का सचमुच मतलब था उन्हें PATCH /threads/{id} से फ़ाइल करते हैं।