Lister les règles
Toutes les règles de la connexion, dans l'ordre où elles sont évaluées.
Exécute le véritable appel sur votre espace de travail, avec votre propre clé.
GET /rules
Toutes les règles de la connexion, dans l'ordre où elles sont évaluées.
Comment une règle s'exécute
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Une règle est une liste de conditions portant sur un message entrant et une liste d'actions à appliquer à tout ce qui y correspond. Les règles appartiennent à la CONNEXION plutôt qu'à celui qui les a écrites. Une clé d'espace de travail voit les mêmes règles qu'un collègue, et supprimer le compte de l'auteur ne les emporte pas.
Une connexion contient 100 règles, et chacune d'elles contient au plus 20 conditions et 10 actions. Ce sont des garde-fous contre les scripts emballés plutôt que des limites de plan : la 101e règle donne rule_limit_reached, un 422, et la 21e condition est refusée par le schéma avant que quoi que ce soit ne soit écrit.
match: "all" combine les conditions par ET, match: "any" par OU, et negate sur une condition isolée est un NON. Il n'y a pas d'arbre booléen imbriqué : (A and B) or C fait deux règles. C'est une décision et non un raccourci. Un schéma récursif ne peut pas être décrit dans le document OpenAPI avec $refStrategy: "none", ne peut pas être remis à un client MCP sous forme de JSON Schema, et c'est exactement la forme qui a déjà fait exploser le plafond d'instanciation de TypeScript dans ce dépôt. Deux règles, c'est aussi la manière dont une personne relit cela six mois plus tard.
Chaque règle activée de la connexion est évaluée contre chaque message entrant, dans l'ordre de position, du plus petit au plus grand. L'évaluation s'arrête après une règle correspondante qui porte stopProcessing: true, et rien en dessous n'est même considéré. Lorsque deux règles correspondantes nomment toutes deux un dossier, c'est la DERNIÈRE qui l'emporte et le message finit dans son dossier, ce qui est la lecture que donne une liste numérotée et la seule chose à dire sur l'ordre plutôt que de la laisser découvrir.
Les règles échouent de façon OUVERTE. Une condition écrite par un client plus ancien, une valeur qui ne se compile pas en motif, une base de données qui ne répond pas : chacun de ces cas est ignoré et le message est livré comme il l'aurait été, l'échec étant consigné dans l'exécution. Un moteur de règles qui lève une exception est un message qui n'arrive jamais ; un moteur de règles ignoré, c'est un message dans le mauvais dossier.
Rien n'est rétroactif. Une règle décide de ce qui arrive au courrier reçu après son existence, et il n'existe délibérément aucun endpoint qui l'applique à une boîte que vous avez déjà. Voir POST /rules/{id}/test, qui répond à la question que les gens posent réellement quand ils réclament cela.
Exemple
Requiert rules:read. limit va jusqu'à 100, cursor est opaque (renvoyez le nextCursor qu'on vous a donné), et enabled restreint à un côté de l'interrupteur.
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 prend les chaînes true et false plutôt qu'un booléen converti, et ce n'est pas du pinaillage : Boolean("false") vaut true, si bien qu'une requête convertie aurait répondu « montre-moi mes règles désactivées » avec les règles activées, en ayant l'air de fonctionner.
L'ordre de la liste est l'ordre d'évaluation : la lire de haut en bas, c'est lire ce qui arrive à un message. position n'est pas unique et n'est pas un id (il est renuméroté par POST /rules/reorder) : repérez donc une règle par son id rul_ et jamais par sa place du moment.
matchCount et lastMatchedAt sont comptés dans la base au fil des arrivées plutôt que lus puis réécrits, si bien que deux messages arrivant en même temps ne peuvent pas perdre un compte en route. Une règle qui ne s'est jamais déclenchée affiche 0 et null, ce qui est la réponse sur laquelle agir quand quelqu'un dit qu'une règle ne fonctionne pas.