Výpis pravidel
Všechna pravidla na spojení, v pořadí, v jakém se vyhodnocují.
Spustí skutečné volání proti vašemu pracovnímu prostoru, s vaším vlastním klíčem.
GET /rules
Všechna pravidla na spojení, v pořadí, v jakém se vyhodnocují.
Jak pravidlo běží
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Pravidlo je seznam podmínek nad příchozí zprávou a seznam akcí, které se mají provést se vším, co jim odpovídá. Pravidla patří SPOJENÍ, ne tomu, kdo je napsal. Klíč pracovního prostoru vidí táž pravidla jako kolega a smazání autorova účtu je s sebou nevezme.
Spojení drží 100 pravidel a každé z nich nejvýš 20 podmínek a 10 akcí. Jsou to pojistky proti utrženému skriptu, ne limity tarifu: 101. pravidlo je rule_limit_reached, 422, a 21. podmínku odmítne schéma dřív, než se cokoli zapíše.
match: "all" spojí podmínky přes AND, match: "any" přes OR a negate na jedné podmínce je NOT. Zanořený booleovský strom neexistuje: (A and B) or C jsou dvě pravidla. Je to rozhodnutí, ne zkratka. Rekurzivní schéma nejde popsat v dokumentu OpenAPI s $refStrategy: "none", nejde předat MCP klientovi jako JSON Schema a je to přesně ten tvar, který v tomto repozitáři už dřív prorazil strop instanciace v TypeScriptu. Dvě pravidla jsou navíc to, jak si to po půl roce přečte člověk.
Každé zapnuté pravidlo na spojení se vyhodnotí proti každé příchozí zprávě, v pořadí podle position, od nejnižší. Vyhodnocování skončí po odpovídajícím pravidle, které nese stopProcessing: true, a nic pod ním se už vůbec nebere v potaz. Když dvě odpovídající pravidla pojmenují složku obě, vyhraje POZDĚJŠÍ a zpráva skončí v jeho složce — tak to čte číslovaný seznam a je to jediná věc o pořadí, kterou stojí za to říct, místo aby se na ni přišlo za pochodu.
Pravidla selhávají SMĚREM K PROPUSTNOSTI. Podmínka, kterou napsal starší klient, hodnota, která se nezkompiluje na vzor, databáze, která neodpoví: každé z toho se přeskočí a zpráva se doručí tak, jak by se doručila, a selhání se zapíše k danému běhu. Engine pravidel, který vyhodí výjimku, je zpráva, která nikdy nedorazí; přeskočený engine pravidel je jedna zpráva ve špatné složce.
Nic nepůsobí zpětně. Pravidlo rozhoduje o poště, která přijde poté, co vzniklo, a endpoint, který by ho pustil na schránku, kterou už máte, tu záměrně není. Viz POST /rules/{id}/test, který odpovídá na otázku, kterou lidé ve skutečnosti kladou, když po tom sahají.
Příklad
Vyžaduje rules:read. limit sahá do 100, cursor je neprůhledný (vracejte zpátky nextCursor, který jste dostali) a enabled zúží výpis na jednu stranu přepínače.
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 bere řetězce true a false, ne přetypovaný boolean, a není to puntičkářství: Boolean("false") je true, takže přetypovaný dotaz by na „ukaž mi moje vypnutá pravidla“ odpověděl těmi zapnutými a vypadal by, že funguje.
Pořadí seznamu je pořadí vyhodnocování, takže číst ho shora dolů znamená číst, co se se zprávou stane. position není unikátní a není to id (přečísluje ho POST /rules/reorder), takže pravidlo držte za jeho id rul_, nikdy ne za to, kde zrovna sedí.
matchCount a lastMatchedAt se počítají v databázi tak, jak pošta přichází, ne čtením a přepsáním, takže dvě zprávy, které dopadnou naráz, mezi sebou nemohou jeden zápočet ztratit. Pravidlo, které se nikdy nespustilo, hlásí 0 a null, a to je odpověď, se kterou se dá pracovat, když někdo řekne, že pravidlo nefunguje.