규칙 목록
연결의 모든 규칙을, 평가되는 순서대로.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
GET /rules
연결의 모든 규칙을, 평가되는 순서대로.
규칙이 실행되는 방식
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"규칙은 도착하는 메시지에 대한 조건 목록과, 그에 일치하는 것에 취할 액션 목록입니다. 규칙은 그것을 쓴 사람이 아니라 연결에 속합니다. 워크스페이스 키는 동료가 보는 것과 같은 규칙을 보고, 작성자의 계정을 삭제해도 규칙이 함께 사라지지는 않습니다.
연결은 규칙 100개를 갖고, 각 규칙은 조건 20개와 액션 10개까지 갖습니다. 플랜 제한이 아니라 폭주하는 스크립트에 대한 방어입니다. 101번째 규칙은 rule_limit_reached, 422이고, 21번째 조건은 아무것도 쓰이기 전에 스키마가 거부합니다.
match: "all"은 조건을 AND로 묶고, match: "any"는 OR로 묶으며, 개별 조건의 negate가 NOT입니다. 중첩 불리언 트리는 없습니다. (A and B) or C는 규칙 두 개입니다. 이것은 지름길이 아니라 결정입니다. 재귀적 스키마는 $refStrategy: "none"으로는 OpenAPI 문서에 기술할 수 없고, MCP 클라이언트에 JSON Schema로 건넬 수도 없으며, 이 저장소에서 전에 TypeScript의 인스턴스화 한도를 터뜨린 바로 그 형태입니다. 규칙 두 개는 여섯 달 뒤에 사람이 다시 읽는 방식이기도 합니다.
연결에서 활성화된 모든 규칙이 도착하는 모든 메시지에 대해 position 오름차순으로 평가됩니다. stopProcessing: true를 가진 규칙이 일치하면 평가가 멈추고, 그 아래는 전혀 고려되지 않습니다. 일치한 두 규칙이 모두 폴더를 지정하면 나중 쪽이 이기고 메시지는 그 폴더로 갑니다. 번호가 매겨진 목록을 읽을 때 자연스러운 해석이며, 순서에 관해 발견에 맡기지 않고 명시할 가치가 있는 유일한 사항입니다.
규칙은 열린 상태로 실패합니다. 오래된 클라이언트가 쓴 조건, 패턴으로 컴파일되지 않는 값, 응답하지 않는 데이터베이스는 모두 건너뛰고 메시지는 원래대로 전달되며, 실패는 해당 실행에 기록됩니다. 예외를 던지는 규칙 엔진은 영영 도착하지 않는 메시지이고, 건너뛴 규칙 엔진은 엉뚱한 폴더에 들어간 메시지 하나입니다.
소급 적용은 없습니다. 규칙은 생긴 뒤에 도착하는 메일에 무슨 일이 일어날지 정하며, 이미 가진 메일함에 규칙을 적용하는 엔드포인트는 의도적으로 없습니다. 사람들이 그것을 찾을 때 실제로 묻고 있는 질문에 답하는 POST /rules/{id}/test를 보십시오.
예제
rules:read가 필요합니다. limit은 100까지, cursor는 불투명하며(받은 nextCursor를 그대로 되돌려 보내십시오), enabled는 스위치의 한쪽으로 좁힙니다.
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는 강제 변환된 boolean이 아니라 문자열 true와 false를 받으며, 이는 까다로움이 아닙니다. Boolean("false")는 true이므로, 강제 변환하는 쿼리라면 "비활성 규칙을 보여줘"에 활성 규칙으로 답하고도 잘 동작하는 것처럼 보였을 것입니다.
목록의 순서가 곧 평가 순서이므로, 위에서 아래로 읽는 것이 메시지에 무슨 일이 일어나는지 읽는 것입니다. position은 고유하지 않고 id도 아니므로(POST /rules/reorder가 다시 번호를 매깁니다), 규칙은 현재 위치가 아니라 rul_ id로 지정하십시오.
matchCount와 lastMatchedAt은 읽어서 다시 쓰는 대신 메일이 도착할 때 데이터베이스에서 카운트되므로, 두 메시지가 동시에 도착해도 그 사이에 카운트를 잃지 않습니다. 한 번도 발동하지 않은 규칙은 0과 null로 읽히며, 누군가 규칙이 동작하지 않는다고 할 때 실제로 움직일 만한 답입니다.