Kalo te dokumentacioni
API

Listo rregullat

Çdo rregull në connection, sipas renditjes me të cilën vlerësohen.

GETapi.openemail.uk/rules

Ekzekuton thirrjen reale kundrejt hapësirës suaj të punës, me çelësin tuaj.

GET /rules

Çdo rregull në connection, sipas renditjes me të cilën vlerësohen.

Si ekzekutohet një rregull

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

Një rregull është një listë kushtesh mbi një mesazh që mbërrin dhe një listë veprimesh për t'u kryer mbi çdo gjë që përputhet me to. Rregullat i përkasin CONNECTION-it dhe jo atij që i shkroi. Një çelës i hapësirës së punës sheh të njëjtat rregulla që sheh një koleg, dhe fshirja e llogarisë së autorit nuk i merr me vete.

Një connection mban 100 rregulla, dhe secili prej tyre mban më së shumti 20 kushte dhe 10 veprime. Këto janë mbrojtje ndaj skripteve të shfrenuara, jo kufij plani: rregulli i 101-të është rule_limit_reached, një 422, ndërsa kushti i 21-të refuzohet nga skema përpara se të shkruhet gjë.

match: "all" i lidh kushtet me AND, match: "any" i lidh me OR, dhe negate mbi një kusht të vetëm është NOT. Nuk ka pemë boolean të ndërthurur: (A and B) or C janë dy rregulla. Kjo është vendim dhe jo shkurtore. Një skemë rekursive nuk mund të përshkruhet në dokumentin OpenAPI me $refStrategy: "none", nuk mund t'i jepet një klienti MCP si JSON Schema, dhe është pikërisht forma që ka çarë tavanin e instancimit të TypeScript-it në këtë repo edhe më parë. Dy rregulla janë edhe mënyra si i lexon prapa një person pas gjashtë muajsh.

Çdo rregull i aktivizuar në connection vlerësohet kundrejt çdo mesazhi që mbërrin, sipas renditjes së position, më i ulëti i pari. Vlerësimi ndalon pas një rregulli përputhës që mbart stopProcessing: true, dhe asgjë nën të nuk merret fare parasysh. Aty ku dy rregulla përputhëse emërtojnë të dyja një dosje, fiton ai i MËVONSHMI dhe mesazhi përfundon në dosjen e tij, që është leximi të cilin ta jep një listë e numëruar dhe e vetmja gjë për renditjen që ia vlen të thuhet, në vend që të lihet për t'u zbuluar.

Rregullat dështojnë NË MËNYRË TË HAPUR. Një kusht i shkruar nga një klient i vjetër, një vlerë që nuk kompilohet në model, një bazë të dhënash që nuk përgjigjet: secila prej tyre kapërcehet dhe mesazhi dorëzohet ashtu si do të ishte dorëzuar, me dështimin e regjistruar te ekzekutimi. Një motor rregullash që hedh përjashtim është një mesazh që nuk mbërrin kurrë; një motor rregullash që kapërcehet është një mesazh në dosjen e gabuar.

Asgjë nuk është retroaktive. Një rregull vendos se çfarë ndodh me postën që mbërrin pasi ai ekziston, dhe qëllimisht nuk ka asnjë endpoint që e zbaton atë mbi një kuti postare që keni tashmë. Shihni POST /rules/{id}/test, që i përgjigjet pyetjes të cilën njerëzit po bëjnë në të vërtetë kur kërkojnë atë.

Shembull

Kërkon rules:read. limit shkon deri në 100, cursor është opak (kthejeni prapa nextCursor-in që ju është dhënë), dhe enabled e ngushton te njëra anë e çelësit.

curl
curl "$OE/rules?limit=25&enabled=true" -H "$AUTH"
Përgjigje
{  "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 merr vargjet true dhe false dhe jo një boolean të konvertuar, dhe kjo nuk është imtësi: Boolean("false") është true, prandaj një query i konvertuar do t'i ishte përgjigjur "më trego rregullat e mia të çaktivizuara" me ato të aktivizuarat dhe do të dukej sikur funksiononte.

Renditja e listës është renditja e vlerësimit, prandaj leximi i saj nga lart poshtë është leximi i asaj që i ndodh një mesazhi. position nuk është unik dhe nuk është id (rinumërohet nga POST /rules/reorder), prandaj identifikojeni një rregull me id-në e tij rul_ dhe kurrë me vendin ku ndodhet tani.

matchCount dhe lastMatchedAt numërohen në bazën e të dhënave ndërsa mbërrin posta, në vend që të lexohen e të rishkruhen, prandaj dy mesazhe që zbarkojnë njëherësh nuk mund të humbin një numërim mes tyre. Një rregull që nuk është aktivizuar kurrë lexon 0 dhe null, që është përgjigjja mbi të cilën ia vlen të veprohet kur dikush thotë se një rregull nuk po punon.