Regeln auflisten
Jede Regel auf der Connection, in der Reihenfolge, in der sie ausgewertet werden.
Führt den echten Aufruf gegen Ihren Workspace aus, mit Ihrem eigenen Schlüssel.
GET /rules
Jede Regel auf der Connection, in der Reihenfolge, in der sie ausgewertet werden.
Wie eine Regel läuft
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Eine Regel ist eine Liste von Bedingungen über eine eingehende Nachricht und eine Liste von Aktionen für alles, was darauf zutrifft. Regeln gehören zur CONNECTION und nicht zu demjenigen, der sie geschrieben hat. Ein Workspace-Key sieht dieselben Regeln wie ein Kollege, und das Löschen des Kontos der Person, die sie angelegt hat, nimmt sie nicht mit.
Eine Connection hält 100 Regeln, und jede davon höchstens 20 Bedingungen und 10 Aktionen. Das sind Schutzgrenzen gegen entlaufene Skripte und keine Plan-Limits: Die 101. Regel ist rule_limit_reached, ein 422, und die 21. Bedingung wird vom Schema abgelehnt, bevor überhaupt etwas geschrieben wird.
match: "all" verknüpft die Bedingungen mit UND, match: "any" mit ODER, und negate an einer einzelnen Bedingung ist NICHT. Es gibt keinen verschachtelten booleschen Baum: (A and B) or C sind zwei Regeln. Das ist eine Entscheidung und keine Abkürzung. Ein rekursives Schema lässt sich im OpenAPI-Dokument mit $refStrategy: "none" nicht beschreiben, kann einem MCP-Client nicht als JSON Schema übergeben werden und ist genau die Form, die in diesem Repo schon einmal die Instanziierungsgrenze von TypeScript gesprengt hat. Zwei Regeln sind außerdem das, was ein Mensch sechs Monate später wieder lesen kann.
Jede aktivierte Regel auf der Connection wird gegen jede eingehende Nachricht ausgewertet, in der Reihenfolge von position, kleinster Wert zuerst. Die Auswertung endet nach einer zutreffenden Regel, die stopProcessing: true trägt, und alles darunter wird überhaupt nicht mehr betrachtet. Wenn zwei zutreffende Regeln beide einen Ordner nennen, gewinnt die SPÄTERE, und die Nachricht landet in deren Ordner; so liest man eine nummerierte Liste, und das ist der eine Punkt zur Reihenfolge, den man aussprechen sollte, statt ihn entdecken zu lassen.
Regeln scheitern OFFEN. Eine Bedingung, die ein älterer Client geschrieben hat, ein Wert, der sich nicht zu einem Muster kompilieren lässt, eine Datenbank, die nicht antwortet: Jedes davon wird übersprungen und die Nachricht wird zugestellt, wie sie es ohnehin geworden wäre, wobei der Fehler zum Lauf protokolliert wird. Eine Regel-Engine, die eine Exception wirft, ist eine Nachricht, die nie ankommt; eine Regel-Engine, die übersprungen wird, ist eine einzelne Nachricht im falschen Ordner.
Nichts wirkt rückwirkend. Eine Regel entscheidet darüber, was mit Mail geschieht, die eingeht, nachdem es sie gibt, und es gibt bewusst keinen Endpunkt, der sie auf ein bereits vorhandenes Postfach anwendet. Siehe POST /rules/{id}/test, das die Frage beantwortet, die tatsächlich gemeint ist, wenn jemand danach greift.
Beispiel
Benötigt rules:read. limit geht bis 100, cursor ist opak (geben Sie den erhaltenen nextCursor zurück), und enabled grenzt auf eine Seite des Schalters ein.
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 nimmt die Strings true und false und keinen erzwungenen boolean, und das ist keine Pedanterie: Boolean("false") ist true, eine erzwungene Query hätte also „zeig mir meine deaktivierten Regeln“ mit den aktivierten beantwortet und dabei ausgesehen, als funktioniere sie.
Die Reihenfolge der Liste ist die Auswertungsreihenfolge; sie von oben nach unten zu lesen heißt zu lesen, was mit einer Nachricht passiert. position ist nicht eindeutig und keine ID (sie wird von POST /rules/reorder neu vergeben); fixieren Sie eine Regel also über ihre rul_-ID und nie über ihre aktuelle Position.
matchCount und lastMatchedAt werden beim Eingang der Mail in der Datenbank hochgezählt, statt gelesen und zurückgeschrieben zu werden; zwei gleichzeitig eintreffende Nachrichten können zwischen sich also keinen Zählwert verlieren. Eine Regel, die nie ausgelöst hat, zeigt 0 und null, und das ist die Antwort, auf die zu reagieren sich lohnt, wenn jemand sagt, eine Regel funktioniere nicht.