Bisedat

GET /threads?folder=inbox. Kalimi i query kërkon në të njëjtin indeks lokal. Fjalët e thjeshta duhet të shfaqen të gjitha, dhe secila përputhet lirshëm, duke shpërfillur shkronjat e mëdha e të vogla, theksat dhe ndarësit, prandaj min gjen "Benjamin". Një frazë në thonjëza përputhet ashtu si është shkruar, përveç shkronjave të mëdha e theksave, prandaj "ben jamin" nuk gjen "Ben-Jamin". Fjalët mbushëse si the ose emails hiqen nga një listë fjalësh të thjeshta kur mbetet diçka tjetër për t'u kërkuar. Operatorë si from:, to:, subject:, label:, is:unread, has:pdf, after:2026/01/31 dhe newer_than:7d e ngushtojnë kërkimin, ndërsa OR, kllapat dhe një - në fillim i kombinojnë. Marrësit ruhen si një listë e vetme pa role dhe nuk mbajnë kurrë një Bcc, prandaj cc: lexon të njëjtën fushë si to: dhe bcc: nuk përputhet me asgjë të vetën. from:me është posta që keni dërguar, ndërsa to:me është posta që mbart një nga adresat tuaja, përfshirë aliaset, mes marrësve të saj ose si adresa te e cila u dorëzua.

Fjalët dhe operatorët from:, to:, cc:, subject: dhe body: lexojnë mesazhin më të ri të secilës bisedë: dërguesin e tij, marrësit, subjektin dhe 4.000 karakteret e para të trupit. filename: dhe has: lexojnë çdo bashkëngjitje të gjithë bisedës, ndërsa label:, in: dhe is: lexojnë gjithë bisedën. folder vazhdon të zbatohet, përveçse kur query-ja emërton një dosje me in:, ose me një is: që është dosje, si is:sent, ndërsa in:anywhere kërkon në çdo dosje, si më vete ashtu edhe pranë termave të tjerë. Listimi i skicave është përjashtimi dhe mbetet te skicat, çfarëdo që të emërtojë query-ja.

Një vlerë që kërkimi nuk mund ta përdorë shpërfillet në vend që të ngushtojë, prandaj një gabim shtypi në një vlerë e zgjeron rezultatin në vend që ta zbrazë: category:, larger:, smaller:, size:, messagesize:, list:, rfc822msgid:, received:, sent:, fjalët e kategorive si is:promotions, një fjalë has: që nuk emërton asnjë lloj bashkëngjitjeje, një importance: i ndryshëm nga high ose low, një datë e palexueshme dhe një kohëzgjatje njësia e së cilës nuk është h, d, w, m ose y. Një emër operatori që ai nuk e njeh, project: për shembull, kërkohet si tekst i thjeshtë. Datat lexojnë aktivitetin më të ri të bisedës, në UTC, ku after: e përfshin ditën që emërton dhe before: e përjashton; shkruajeni një të tillë si YYYY/MM/DD, YYYY-MM-DD, YYYYMMDD, si vit i thjeshtë, ose si sekonda a milisekonda epoch.

GET /threads/{id} kthen çdo mesazh të bisedës, jo vetëm më të fundit, bashkë me etiketat e saj dhe me faktin nëse ka ndonjë gjë të palexuar në të.

Kjo API as enkripton dhe as deshifron. Ajo nuk mund të hapë një mesazh që e enkriptoi dikush tjetër, dhe nuk mund të dërgojë një të enkriptuar. Një kërkesë që mbart një shënues enkriptimi refuzohet me një 422, sepse të vetmet sipërfaqe që mund ta vendosin një të tillë janë ato që mbajnë çelësat, dhe asnjë klient API nuk mban çelës. Ajo që bën është të NJOHË një zarf të vulosur gjatë hyrjes, nga Content-Type-i i nivelit të parë dhe asgjë më shumë, dhe pastaj ta thotë atë te mesazhi.

OpenEmail tani mban vetë çelësa, dhe ia vlen të jemi të saktë se cilën gjysmë dhe ku. Pronari i një kutie postare gjeneron një identitet OpenPGP në shfletuesin e tij dhe publikon çelësin PUBLIK në një drejtori që mund ta zgjidhin dërgues të tjerë OpenEmail të identifikuar. Gjysma private krijohet në atë shfletues, nuk dërgohet kurrë këtu dhe nuk rikthehet kurrë, prandaj asgjë në këtë API nuk mund të deshifrojë asgjë, dhe asnjë kërkesë mbështetjeje, urdhër gjyqësor apo kopje rezervë e jona nuk prodhon një çelës që të mundej. Aplikacioni web tani mund të HAPË një mesazh PGP/MIME ose PGP inline kur çelësi ndodhet në shfletuesin e lexuesit, por ai deshifrim ndodh në skedë dhe teksti i tij i hapur nuk shkruhet kurrë mbrapsht: mesazhi i ruajtur mbetet tekst i shifruar, dhe asnjë përgjigje e kësaj API-je nuk mbart kurrë tekstin e hapur. Aplikacioni tani mund ta vulosë një mesazh të ri në shfletues dhe ta dërgojë: kompozuesi enkripton drejt çelësave të publikuar të marrësve dhe posta niset si PGP/MIME. Kjo API ende nuk mund të vulosë asgjë, prandaj fusha më poshtë përshkruan si postën që e enkriptoi dikush tjetër, ashtu edhe postën e vulosur në një skedë të OpenEmail-it.

Kjo meriton një fushë për shkak të asaj që ishte alternativa. Një mesazh i vulosur nuk ruan asnjë trup të lexueshëm, prandaj decodedBody kthehet si "", po ato bajte si një mesazh që në të vërtetë nuk kishte përmbajtje. encryption është ajo që ju lejon t'i dalloni të dyja përpara se të veproni mbi njërën, dhe është pohim për zarfin dhe jo verifikim: të shohësh se një mesazh është i vulosur nuk është njësoj si ta kesh hapur.

{    "object": "thread",    "id": "thread_2f9b…",    "messages": [      {        "id": "msg_7c41…",        "subject": "Q3 numbers",        "decodedBody": "",        "encryption": {          "format": "pgp-mime",          "detectedAt": "2026-08-30T09:14:22.117Z",          "rawRetained": false,          "parts": [            { "index": 0, "attachmentId": "msg_7c41…-0", "role": "version" },            { "index": 1, "attachmentId": "msg_7c41…-1", "role": "ciphertext" }          ]        }      }    ]  }

Vetëm tre formatet e vulosura ndryshojnë diçka, dhe ndryshimi ndodh në fazën e futjes, jo në këtë përgjigje. Çdo gjë që do ta kishte lexuar trupin tërhiqet, në vend që të lexojë tekst të shifruar dhe të raportojë një rezultat që nuk mund ta kishte nxjerrë:

• —Kërkimi mbi trupin. Mesazhi indeksohet me një fragment trupi bosh, prandaj gjendet ende nga dërguesi, subjekti, adresa dhe etiketa, dhe jo nga asgjë brenda tij.
• —Kalimi mbi trupin i vlerësuesit të phishing-ut. Verdikti mbërrin gjithsesi dhe thotë çfarë nuk mundi të bënte: risk.signals mbart body-encrypted dhe risk.aiChecked është false.
• —Kontrolli i autorësisë nga AI, i cili refuzon në vend që të hamendësojë: aiWritten.level është unknown dhe aiWritten.skipped është encrypted.
• —Kushtet mbi trupin te rregullat. Kushtet mbi zarfin dhe headerët ekzekutohen pikërisht si më parë; një rregull që pyeste për trupin regjistrohet si i pavlerësuar dhe jo si mospërputhje, sepse "nuk u përputh" dhe "nuk mund të lexohej" janë përgjigje të ndryshme.
• —Importimi i ftesave të kalendarit. Ftesa është brenda tekstit të shifruar, dhe ndërtimi i një ngjarjeje nga zarfi do të vendoste një zë të gabuar në një kalendar të vërtetë.
• —Përmbledhjet dhe embedding-et e bisedave, për të gjithë bisedën. Mjafton një përgjigje e vetme e vulosur. Një përmbledhje është leximi i një modeli mbi tekstin e hapur, i ruajtur si metadata e qartë, që është i vetmi vend në këtë rrjedhë ku një trup do të rridhte në një depo që askush nuk e mendon si trup.

Çdo gjë që nuk ka nevojë për trupin mbetet e paprekur:

• —DMARC, DKIM dhe SPF. Ato lexohen nga Authentication-Results, të cilin teksti i shifruar nuk e fsheh, prandaj një mesazh i enkriptuar merr gjithsesi një verdikt të vërtetë autentikimi dhe jo asnjë.
• —Grupimi në biseda, arkivimi i spam-it dhe lista e bllokimit: të gjitha punë mbi zarfin dhe headerët.
• —Bashkëngjitjet. Pjesa ciphertext mbetet te attachments, e emërtuar encrypted-message.asc kur mbërrin pa emër, dhe shkarkohet përmes endpoint-it më poshtë. Është pikërisht ajo që merr dhe deshifron në shfletues lexuesi i vetë aplikacionit web; për një klient API, i cili nuk mban asnjë çelës, ai shkarkim mbetet e vetmja mënyrë për ta lexuar postën. Hapeni në një klient që ka një çelës.
• —Një mesazh i nënshkruar nuk humb asgjë nga kjo. Çdo kontroll i mësipërm vazhdon të ekzekutohet mbi të dhe asgjë nuk mbahet mbrapsht, prandaj lista e të vulosurve është listë me tre formate dhe jo me pesë.

PATCH /threads/{id} merr read, addLabelIds dhe removeLabelIds. Gjendja e leximit është etiketë në çdo backend që mbështet ky produkt, prandaj caktimi i read dhe zhvendosja e etiketave në një thirrje të vetme e mban renditjen deterministe.

{ "read": true, "addLabelIds": ["USER_INVOICES"] }

GET /threads/{id}/messages/{messageId}/attachments kthen çdo bashkëngjitje me filename, contentType, size dhe content si base64. content është varg bosh aty ku bajtet e ruajtura nuk u gjetën dot, prandaj kontrolloni gjatësinë e tij përpara se të dekodoni.