नियम सूचीबद्ध करें
कनेक्शन का हर नियम, उसी क्रम में जिसमें उनका मूल्यांकन होता है।
असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।
GET /rules
कनेक्शन का हर नियम, उसी क्रम में जिसमें उनका मूल्यांकन होता है।
नियम कैसे चलता है
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"नियम आने वाले संदेश पर शर्तों की सूची और उनसे मेल खाने वाली हर चीज़ पर की जाने वाली कार्रवाइयों की सूची है। नियम कनेक्शन के होते हैं, उसके नहीं जिसने उन्हें लिखा। वर्कस्पेस कुंजी वही नियम देखती है जो कोई सहकर्मी देखता है, और लेखक का खाता हटाने से वे साथ नहीं जाते।
एक कनेक्शन 100 नियम रखता है, और उनमें से हर एक अधिकतम 20 शर्तें और 10 कार्रवाइयाँ। ये प्लान की सीमाएँ नहीं, बेकाबू स्क्रिप्ट से बचाव हैं: 101वाँ नियम rule_limit_reached, एक 422 है, और 21वीं शर्त कुछ लिखे जाने से पहले ही स्कीमा द्वारा मना कर दी जाती है।
match: "all" शर्तों को AND करता है, match: "any" उन्हें OR करता है, और किसी एक शर्त पर negate NOT है। नेस्टेड बूलियन वृक्ष नहीं है: (A and B) or C दो नियम हैं। यह शॉर्टकट नहीं, एक निर्णय है। रिकर्सिव स्कीमा को $refStrategy: "none" के साथ OpenAPI दस्तावेज़ में वर्णित नहीं किया जा सकता, MCP क्लाइंट को JSON Schema के रूप में नहीं थमाया जा सकता, और यही वह आकार है जिसने इस रेपो में पहले भी TypeScript की instantiation सीमा उड़ाई है। छह महीने बाद कोई व्यक्ति भी उसे दो नियमों के रूप में ही पढ़ेगा।
कनेक्शन के हर सक्षम नियम का मूल्यांकन हर आने वाले संदेश पर होता है, position क्रम में, सबसे छोटे से शुरू। ऐसे मेल खाते नियम के बाद मूल्यांकन रुक जाता है जिस पर stopProcessing: true है, और उसके नीचे कुछ भी नहीं देखा जाता। जहाँ दो मेल खाते नियम दोनों किसी फ़ोल्डर का नाम लेते हैं, वहाँ बाद वाला जीतता है और संदेश उसी के फ़ोल्डर में पहुँचता है — क्रमांकित सूची से यही पाठ बनता है, और क्रम के बारे में यही एक बात बताने लायक है, खोजे जाने पर छोड़ने लायक नहीं।
नियम खुले में विफल होते हैं। पुराने क्लाइंट की लिखी शर्त, ऐसा मान जो पैटर्न में कंपाइल नहीं होगा, ऐसा डेटाबेस जो जवाब नहीं देगा: इनमें से हर एक को छोड़ दिया जाता है और संदेश वैसे ही डिलीवर होता है जैसे होता, विफलता उस run के विरुद्ध लॉग करके। ऐसा नियम-इंजन जो अपवाद फेंके, वह एक संदेश है जो कभी पहुँचता ही नहीं; छोड़ दिया गया नियम-इंजन एक संदेश है जो गलत फ़ोल्डर में है।
कुछ भी पूर्वव्यापी नहीं है। नियम तय करता है कि उसके बनने के बाद आने वाली मेल का क्या होगा, और जानबूझकर ऐसा कोई एंडपॉइंट नहीं जो उसे आपके पास पहले से मौजूद मेलबॉक्स पर लागू करे। 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 जबरन बदले गए बूलियन के बजाय स्ट्रिंग true और false लेता है, और यह नख़रा नहीं है: Boolean("false") true होता है, इसलिए जबरन बदली गई query "मेरे अक्षम नियम दिखाओ" का जवाब सक्षम नियमों से देती और ऐसा लगता जैसे काम कर रही हो।
सूची का क्रम ही मूल्यांकन का क्रम है, इसलिए उसे ऊपर से नीचे पढ़ना यह पढ़ना है कि संदेश के साथ क्या होगा। position अद्वितीय नहीं है और id नहीं है (उसे POST /rules/reorder दोबारा क्रमांकित करता है), इसलिए नियम को उसकी rul_ id से पकड़ें, कभी उसकी मौजूदा जगह से नहीं।
matchCount और lastMatchedAt मेल आते ही डेटाबेस में गिने जाते हैं, पढ़कर दोबारा लिखे नहीं जाते, इसलिए एक साथ आए दो संदेशों के बीच कोई गिनती खो नहीं सकती। जो नियम कभी नहीं चला वह 0 और null बताता है — और जब कोई कहे कि नियम काम नहीं कर रहा, तो यही जवाब काम का है।