Szabályok listázása
A kapcsolat minden szabálya, a kiértékelésük sorrendjében.
A valódi hívást futtatja le a munkaterületén, a saját kulcsával.
GET /rules
A kapcsolat minden szabálya, a kiértékelésük sorrendjében.
Hogyan fut egy szabály
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Egy szabály feltételek listája egy beérkező üzenetre vonatkozóan, és műveletek listája mindenre, ami egyezik velük. A szabályok a KAPCSOLATHOZ tartoznak, nem ahhoz, aki megírta őket. Egy munkaterületi kulcs ugyanazokat a szabályokat látja, mint egy kolléga, és a szerző fiókjának törlése nem viszi magával őket.
Egy kapcsolat 100 szabályt tartalmazhat, és mindegyik legfeljebb 20 feltételt és 10 műveletet. Ezek elszabadult szkriptek elleni védelmek, nem csomagkorlátok: a 101. szabály rule_limit_reached, 422, a 21. feltételt pedig már a séma elutasítja, mielőtt bármi íródna.
A match: "all" ÉS kapcsolatba hozza a feltételeket, a match: "any" VAGY kapcsolatba, és a negate egyetlen feltételen NEM. Nincs beágyazott logikai fa: az (A and B) or C két szabály. Ez döntés, nem rövidítés. Egy rekurzív séma nem írható le az OpenAPI dokumentumban $refStrategy: "none" mellett, nem adható át egy MCP kliensnek JSON Schema formában, és pontosan ez az a forma, amely ebben a repóban korábban már túllépte a TypeScript példányosítási plafonját. Ráadásul két szabály az, amit egy ember hat hónappal később is vissza tud olvasni.
A kapcsolat minden engedélyezett szabálya kiértékelésre kerül minden beérkező üzenetre, position sorrendben, a legalacsonyabbtól kezdve. A kiértékelés leáll egy olyan egyező szabály után, amely stopProcessing: true értéket tartalmaz, és az alatta lévők egyáltalán nem kerülnek figyelembe vételre. Ha két egyező szabály is mappát nevez meg, a KÉSŐBBI nyer, és az üzenet annak mappájába kerül, ami egy számozott lista természetes olvasata, és a sorrendről ez az egyetlen dolog, amelyet érdemes kimondani, ahelyett hogy felfedezésre várna.
A szabályok NYITOTT módon hibáznak. Egy régebbi kliens által írt feltétel, egy mintává nem fordítható érték, egy nem válaszoló adatbázis: mindegyik kihagyásra kerül, és az üzenet úgy kerül kézbesítésre, ahogy különben is került volna, a hibát pedig a futás naplózza. Egy kivételt dobó szabálymotor egy soha meg nem érkező üzenet; egy kihagyott szabálymotor egy rossz mappába került üzenet.
Semmi nem visszamenőleges. Egy szabály az azután érkező levelekről dönt, hogy létrejött, és szándékosan nincs olyan végpont, amely egy már meglévő postafiókra alkalmazná. Lásd a POST /rules/{id}/test hívást, amely arra a kérdésre felel, amelyet az emberek valójában feltesznek, amikor ilyet keresnek.
Példa
rules:read szükséges. A limit legfeljebb 100, a cursor átlátszatlan (a kapott nextCursor értéket add vissza), az enabled pedig a kapcsoló egyik oldalára szűkít.
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}Az enabled a true és false stringeket fogadja, nem egy kikényszerített booleant, és ez nem akadékoskodás: a Boolean("false") értéke true, így egy kikényszerített lekérdezés a „mutasd a kikapcsolt szabályaimat” kérésre a bekapcsoltakkal válaszolt volna, és úgy tűnt volna, hogy működik.
A lista sorrendje a kiértékelési sorrend, így fentről lefelé olvasva azt olvasod, mi történik egy üzenettel. A position nem egyedi és nem azonosító (a POST /rules/reorder újraszámozza), ezért egy szabályt a rul_ azonosítója alapján rögzíts, soha ne a jelenlegi helye alapján.
A matchCount és a lastMatchedAt a levelek érkezésekor az adatbázisban számlálódik, nem kiolvasás és visszaírás útján, így két egyszerre érkező üzenet nem veszíthet el egy számlálást egymás között. Egy soha le nem futott szabály 0 és null értéket mutat, és erre érdemes reagálni, amikor valaki azt mondja, hogy egy szabály nem működik.