تخطَّ إلى المستندات
API

سرد القواعد

كل قاعدة على الاتصال، بالترتيب الذي تُقيَّم به.

GETapi.openemail.uk/rules

ينفّذ الاستدعاء الحقيقي على مساحة عملك، بمفتاحك أنت.

GET /rules

كل قاعدة على الاتصال، بالترتيب الذي تُقيَّم به.

كيف تعمل القاعدة

shell
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 هي قاعدتان. وهذا قرار لا اختصار. فالمخطط التعاودي لا يمكن وصفه في مستند OpenAPI مع $refStrategy: "none"، ولا يمكن تسليمه إلى عميل MCP كـ JSON Schema، وهو بالضبط الشكل الذي فجّر سقف التنصيب في TypeScript في هذا المستودع من قبل. وقاعدتان هما أيضًا كيف يقرأ الشخص ذلك بعد ستة أشهر.

تُقيَّم كل قاعدة مفعَّلة على الاتصال في مقابل كل رسالة واردة، بترتيب position، الأدنى أولًا. ويتوقف التقييم بعد قاعدة مطابِقة تحمل stopProcessing: true، ولا يُنظَر إطلاقًا فيما تحتها. وحين تسمّي قاعدتان مطابقتان مجلدًا، تفوز اللاحقة وتنتهي الرسالة في مجلدها، وهي القراءة التي تعطيك إياها قائمة مرقّمة والشيء الوحيد في الترتيب الجدير بالتصريح بدل تركه ليُكتشَف.

القواعد تفشل مفتوحة. فشرط كتبه عميل أقدم، أو قيمة لن تُترجَم إلى نمط، أو قاعدة بيانات لا تجيب: كلٌّ من ذلك يُتخطّى وتُسلَّم الرسالة كما كانت ستُسلَّم، مع تسجيل الإخفاق في سجل التشغيل. فمحرك قواعد يرمي استثناءً هو رسالة لا تصل أبدًا؛ ومحرك قواعد يُتخطّى هو رسالة واحدة في المجلد الخطأ.

لا شيء بأثر رجعي. فالقاعدة تقرر ما يحدث للبريد الواصل بعد وجودها، ولا توجد عمدًا نقطة نهاية تطبّق واحدة على صندوق بريد لديك أصلًا. انظر 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 يأخذ السلسلتين true وfalse لا قيمة منطقية مُقسَرة، وهذا ليس تزمّتًا: فـ Boolean("false") هو true، فالاستعلام المُقسَر كان سيجيب «أرني قواعدي المعطَّلة» بالمفعَّلة ويبدو وكأنه عمل.

ترتيب القائمة هو ترتيب التقييم، فقراءتها من أعلى إلى أسفل هي قراءة لما يحدث لرسالة. وposition ليست فريدة وليست معرّفًا (فهي يعاد ترقيمها بـ POST /rules/reorder)، فثبّت القاعدة بمعرّف rul_ الخاص بها لا بموقعها الحالي أبدًا.

matchCount وlastMatchedAt تُحسبان في قاعدة البيانات مع وصول البريد لا بالقراءة ثم إعادة الكتابة، فرسالتان تصلان معًا لا يمكن أن تضيع بينهما عدّة. والقاعدة التي لم تُطلق قط تقرأ 0 وnull، وهي الإجابة الجديرة بالتصرف حين يقول أحدهم إن قاعدة لا تعمل.