Saltar para a documentação
API

Listar regras

Todas as regras da ligação, pela ordem em que são avaliadas.

GETapi.openemail.uk/rules

Executa a chamada real contra o seu espaço de trabalho, com a sua própria chave.

GET /rules

Todas as regras da ligação, pela ordem em que são avaliadas.

Como uma regra corre

shell
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"

Uma regra é uma lista de condições sobre uma mensagem que chega e uma lista de ações a tomar sobre tudo o que lhes corresponda. As regras pertencem à LIGAÇÃO e não a quem escreveu uma. Uma chave de espaço de trabalho vê as mesmas regras que um colega vê, e eliminar a conta de quem as escreveu não as leva com ela.

Uma ligação tem 100 regras, e cada uma delas tem no máximo 20 condições e 10 ações. São proteções contra scripts desgovernados e não limites de plano: a 101.ª regra é rule_limit_reached, um 422, e a 21.ª condição é recusada pelo esquema antes de algo ser escrito.

match: "all" junta as condições com AND, match: "any" junta-as com OR, e negate numa condição isolada é NOT. Não há árvore booleana aninhada: (A and B) or C são duas regras. Isso é uma decisão e não um atalho. Um esquema recursivo não pode ser descrito no documento OpenAPI com $refStrategy: "none", não pode ser entregue a um cliente MCP como JSON Schema, e é exatamente a forma que já rebentou com o tecto de instanciação do TypeScript neste repositório. Duas regras são também a forma como uma pessoa relê isto seis meses depois.

Todas as regras ativas da ligação são avaliadas contra todas as mensagens que chegam, por ordem de position, da mais baixa primeiro. A avaliação para depois de uma regra correspondente que traga stopProcessing: true, e nada abaixo dela é sequer considerado. Quando duas regras correspondentes nomeiam ambas uma pasta, ganha a ÚLTIMA e a mensagem acaba na pasta dela, que é a leitura que uma lista numerada sugere e a única coisa sobre a ordem que vale a pena dizer em vez de deixar para descobrir.

As regras falham ABERTAS. Uma condição escrita por um cliente antigo, um valor que não compila para um padrão, uma base de dados que não responde: cada uma delas é saltada e a mensagem é entregue como o teria sido, com a falha registada na execução. Um motor de regras que lança um erro é uma mensagem que nunca chega; um motor de regras que é saltado é uma mensagem na pasta errada.

Nada é retroativo. Uma regra decide o que acontece ao correio que chega depois de ela existir, e não há deliberadamente nenhum endpoint que a aplique a uma caixa de correio que já tem. Ver POST /rules/{id}/test, que responde à pergunta que as pessoas estão realmente a fazer quando pedem isso.

Exemplo

Requer rules:read. limit vai até 100, cursor é opaco (devolva o nextCursor que lhe foi dado), e enabled restringe a um dos lados do interruptor.

curl
curl "$OE/rules?limit=25&enabled=true" -H "$AUTH"
Resposta
{  "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 aceita as strings true e false em vez de um boolean convertido, e isso não é preciosismo: Boolean("false") é true, por isso uma query convertida teria respondido a "mostra-me as minhas regras desativadas" com as ativadas e parecido que funcionava.

A ordem da lista é a ordem de avaliação, por isso lê-la de cima para baixo é ler o que acontece a uma mensagem. position não é único e não é um id (é renumerado por POST /rules/reorder), por isso identifique uma regra pelo seu id rul_ e nunca pelo sítio onde está agora.

matchCount e lastMatchedAt são contados na base de dados à medida que o correio chega, em vez de lidos e reescritos, por isso duas mensagens a chegar ao mesmo tempo não podem perder uma contagem entre si. Uma regra que nunca disparou lê 0 e null, que é a resposta sobre a qual vale a pena agir quando alguém diz que uma regra não está a funcionar.