Regels opsommen
Elke regel op de connectie, in de volgorde waarin ze geëvalueerd worden.
Voert de echte aanroep uit op je workspace, met je eigen sleutel.
GET /rules
Elke regel op de connectie, in de volgorde waarin ze geëvalueerd worden.
Hoe een regel draait
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Een regel is een lijst voorwaarden over een binnenkomend bericht en een lijst acties die worden uitgevoerd op alles wat eraan voldoet. Regels horen bij de CONNECTIE en niet bij degene die ze geschreven heeft. Een workspace-key ziet dezelfde regels als een collega, en het account van de auteur verwijderen neemt ze niet mee.
Een connectie houdt 100 regels, en elke regel houdt hooguit 20 voorwaarden en 10 acties. Dat zijn beveiligingen tegen op hol geslagen scripts en geen abonnementslimieten: de 101e regel is rule_limit_reached, een 422, en de 21e voorwaarde wordt door het schema geweigerd voordat er iets geschreven wordt.
match: "all" verbindt de voorwaarden met AND, match: "any" met OR, en negate op één voorwaarde is NOT. Er is geen geneste booleaanse boom: (A and B) or C zijn twee regels. Dat is een keuze en geen kortere weg. Een recursief schema is in het OpenAPI-document met $refStrategy: "none" niet te beschrijven, kan niet als JSON Schema aan een MCP-client gegeven worden, en is precies de vorm die in deze repo eerder het instantiatieplafond van TypeScript heeft opgeblazen. Twee regels is ook hoe een mens het zes maanden later terugleest.
Elke ingeschakelde regel op de connectie wordt op elk binnenkomend bericht geëvalueerd, in volgorde van position, laagste eerst. De evaluatie stopt na een matchende regel met stopProcessing: true, en wat eronder staat wordt helemaal niet meer bekeken. Als twee matchende regels allebei een map noemen, wint de LATERE en belandt het bericht in diens map, wat de lezing is die een genummerde lijst je geeft en het ene punt over volgorde dat het vermelden waard is in plaats van het te laten ontdekken.
Regels falen OPEN. Een voorwaarde die een oudere client schreef, een waarde die niet tot een patroon compileert, een database die niet antwoordt: elk daarvan wordt overgeslagen en het bericht wordt afgeleverd zoals het afgeleverd zou zijn, met de fout gelogd bij de uitvoering. Een regel-engine die een fout gooit is een bericht dat nooit aankomt; een regel-engine die wordt overgeslagen is één bericht in de verkeerde map.
Niets werkt met terugwerkende kracht. Een regel bepaalt wat er gebeurt met mail die binnenkomt nadat hij bestaat, en er is bewust geen endpoint dat er een toepast op een mailbox die je al hebt. Zie POST /rules/{id}/test, dat de vraag beantwoordt die mensen eigenlijk stellen als ze daarnaar grijpen.
Voorbeeld
Vereist rules:read. limit gaat tot 100, cursor is ondoorzichtig (stuur de nextCursor terug die je gekregen hebt), en enabled beperkt tot één kant van de schakelaar.
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 neemt de strings true en false in plaats van een omgezette boolean, en dat is geen muggenzifterij: Boolean("false") is true, dus een omgezette query zou "laat mijn uitgeschakelde regels zien" hebben beantwoord met de ingeschakelde en eruit hebben gezien alsof het werkte.
De volgorde van de lijst is de evaluatievolgorde, dus hem van boven naar beneden lezen is lezen wat er met een bericht gebeurt. position is niet uniek en is geen id (het wordt hernummerd door POST /rules/reorder), dus leg een regel vast op zijn rul_-id en nooit op waar hij nu staat.
matchCount en lastMatchedAt worden in de database geteld terwijl de mail binnenkomt, in plaats van gelezen en teruggeschreven, zodat twee berichten die tegelijk landen geen telling tussen zich in kunnen verliezen. Een regel die nooit is afgegaan leest 0 en null, en dat is het antwoord waarop je moet handelen als iemand zegt dat een regel niet werkt.