SDK

Bisedat

`threads.list`, `listAll`, `iterate`, `get`, `update`, `trash`, `snooze`, `unsnooze` dhe `listAttachments`.

Leximi

read-threads.ts

const page = await openemail.threads.list({  folder: 'inbox',  query: 'from:ada',  labelIds: ['INBOX', 'IMPORTANT'],  limit: 25,}) const next = page.nextCursor  ? await openemail.threads.list({ folder: 'inbox', cursor: page.nextCursor })  : null const thread = await openemail.threads.get('thread_…')console.log(thread.messageCount, thread.hasUnread, thread.totalReplies)

API-ja i ndan bisedat në faqe me një pageToken. Klienti jua jep si nextCursor dhe e merr prapë si cursor, si çdo listë tjetër, kurse listAll dhe iterate e ndjekin atë për ju. Ai është i errët: ktheni atë që ju u dha dhe mos ndërtoni kurrë një të tillë.

Organizimi

organise-threads.ts

await openemail.threads.update('thread_…', {  read: true,  addLabelIds: ['Done'],  removeLabelIds: ['INBOX'],}) await openemail.threads.trash('thread_…')await openemail.threads.snooze('thread_…', new Date(Date.now() + 86_400_000))await openemail.threads.unsnooze('thread_…')

Gjendja e leximit ËSHTË një etiketë në çdo backend këtu, ndaj udhëton bashkë me listat e etiketave dhe renditja është deterministe kur i vendosni të dyja. Të paktën njëra nga tri fushat duhet të jetë e pranishme.

Bashkëngjitjet e një mesazhi

attachments.ts

const files = await openemail.threads.listAttachments('thread_…', 'message_…') for (const file of files) {  console.log(file.filename, file.contentType, file.size)  if (file.content) await save(file.filename, Buffer.from(file.content, 'base64'))}

content është base64, dhe një varg bosh kur bajtat e ruajtur nuk u gjetën dot, ndaj kontrolloni gjatësinë e tij para se ta dekodoni. Teksti i shifruar i një mesazhi të enkriptuar ËSHTË në këtë listë dhe shkarkohet si çdo skedar tjetër; pjesa e versionit PGP/MIME dhe çdo nënshkrim i shkëputur nuk janë. Ato i mbajnë id-të e veta te encryption.parts dhe asgjë më shumë.

Një mesazh që mbërriti i enkriptuar

Ky SDK as enkripton, as dekripton: nuk mund të hapë një mesazh që e enkriptoi dikush tjetër dhe nuk mund të dërgojë një mesazh të enkriptuar. Kërkesa e dërgimit refuzohet nëse mbart një shenjues enkriptimi, sepse një klient pa çelës nuk ka pse të pohojë një të tillë. Çelësat e gjeneruar në aplikacionin OpenEmail jetojnë në shfletuesin që i krijoi dhe nuk mbërrijnë askund këtu; kur ai shfletues hap një mesazh të vulosur, teksti i qartë mbetet brenda tij, kurse mesazhi i ruajtur që lexon kjo thirrje mbetet tekst i shifruar. Ajo që ju jep threads.get është zarfi, i njohur si i tillë. Një mesazh që mbërriti i mbështjellë me PGP ose S/MIME mbart një objekt encryption, kështu që një decodedBody bosh pushon së qeni e vetmja gjë që ju jepet; dhe encryption është e vetmja fushë te MessageResource me tip të vërtetë, sepse është ajo mungesën e së cilës nuk e kaloni dot duke hamendësuar.

encrypted-mail.ts

import { isSealed, openemail } from '@openemail/sdk' const thread = await openemail.threads.get('thread_…') for (const message of thread.messages) {  if (!message.encryption) continue  if (!isSealed(message)) continue   console.warn('cannot read this one:', message.encryption.format)}

Degëzoni me isSealed, kurrë sipas pranisë së fushës. Dy nga pesë formatet, pgp-signed dhe smime-signed, përshkruajnë një trup që mbërriti I HAPUR përkrah një nënshkrimi të shkëputur, ndaj kushtëzimi sipas pranisë fsheh postë që nuk kishte pse fshihej, dhe përdoruesi as e sheh dot, as e shpjegon dot. isSealed vjen i gatshëm pikërisht për këtë arsye: serveri e deklaron një herë të vetme bashkësinë e të vulosurave, kurse një kopje e tretë e shkruar nga union-i është kopja që rrëshqet.

Mungesa nuk do të thotë tekst i qartë. encryption mungon në çdo mesazh të ruajtur para se të dilte zbulimi, si dhe në çdo gjë që mbërriti në kutinë postare përmes një rruge ku zbuluesi nuk u ekzekutua kurrë. Ajo regjistron faktin që askush nuk shikoi — një fakt për mbulimin tonë e jo për vetë postën — dhe asgjë nuk e mbush atë në mënyrë retroaktive.

Ku ndryshojnë këto nga të tjerat

Çdo zë te ThreadResource.messages është një MessageResource, një Record<string, unknown> me saktësisht një fushë të emërtuar mbi të. Tipizimi i pjesës tjetër do të ishte klienti që pohon një normalizim të cilin nuk e kryen askush, kurse encryption emërtohet gjithsesi, sepse një klient që nuk degëzon dot sipas saj e lexon një mesazh të vulosur si mesazh bosh.
Një kërkesë që nuk mund të shërbehet me besnikëri është një 422 capability_unsupported, jo një përgjigje që duket e saktë dhe është në heshtje e gabuar.

Parametrat: threads.list (ThreadListOptions)

folderstring: Cila dosje të listohet. Serveri e vendos si parazgjedhje `inbox`, ndaj lënia e tij jashtë e ngushton listimin në vend që ta zgjerojë te gjithçka. Ai vlen edhe për një kërkim me `query`, veç nëse vetë pyetja emërton një dosje me `in:` ose me një `is:` dosjeje, si `is:sent`.
querystring: Sintaksa e kërkimit në kutinë postare. Fjalët e thjeshta duhet të shfaqen të gjitha dhe secila përputhet në mënyrë të lirshme: shkronjat e mëdha a të vogla, theksat dhe ndarësit shpërfillen, kurse pjesa e një fjale më të gjatë numërohet, ndaj si `min`, ashtu edhe `ben jamin` e gjejnë "Benjamin". Një frazë në thonjëza përputhet ashtu siç është shkruar, përveç shkronjave të mëdha a të vogla dhe theksave, ndaj `"ben jamin"` nuk e gjen "Ben-Jamin"; fjalët mbushëse hidhen tej kur mbetet diçka tjetër për të kërkuar. Ngushtojeni me operatorë si `from:ada`, `label:Invoices`, `is:unread`, `has:pdf`, `before:2026/01/31` dhe `older_than:1y`, dhe kombinojini me `OR`, me kllapa dhe me një `-` në fillim; një vlerë që kërkimi nuk e përdor dot shpërfillet në vend që të ngushtojë. Fjalët dhe operatorët `from:`, `to:`, `cc:`, `subject:` e `body:` lexojnë dërguesin, marrësit, temën e mesazhit më të fundit dhe 4.000 karakteret e para të trupit të tij me markup-in e hequr, ndërsa `filename:` dhe `has:` lexojnë çdo bashkëngjitje të gjithë bisedës, kurse etiketat dhe dosjet lexojnë gjithë bisedën. Ai ngushton të njëjtin indeks që lexon listimi i pafiltruar. Mesazhet e vulosura nuk ruajnë tekst trupi, ndaj mund të përputhen vetëm dërguesi, marrësit dhe tema e tyre.
labelIdsstring | string[]: Kufizojeni listimin te bisedat që mbajnë këto etiketa. Endpoint-i merr një varg të ndarë me presje dhe klienti jua bashkon një array në një të tillë; nuk ka kufi se sa prej tyre emërtoni.
limitnumber: Sa biseda të kthehen, nga 1 deri në 100. Nëse lihet jashtë, handler-i përdor 25. Vlera e parazgjedhur qëndron te handler-i e jo te skema, ndaj një vlerë që mungon dhe një 25 e shprehur sillen njësoj.
cursorstring: `nextCursor`-i i faqes së mëparshme, i kthyer fjalë për fjalë. Është `pageToken`-i i API-së nën emrin që përdor çdo listë tjetër, dhe është i errët, ndaj mos ndërtoni e mos redaktoni kurrë një të tillë.

Përgjigjja: Page<ThreadSummaryResource>

itemsThreadSummaryResource[]: Një zë për çdo bisedë në këtë faqe, i nxjerrë nga zarfi `data` i API-së. Çdo zë është vetëm një shenjues objekti dhe një id. Listimi nuk mbart temë, fragment, pjesëmarrës apo etiketa, ndaj çdo gjë më shumë do të thotë të thirret `threads.get` për bisedat që doni.
items[].idstring: Id-ja e bisedës, për t'ia dhënë të pandryshuar `threads.get`, `threads.update` dhe të tjerave. Është e njëjta id, qoftë kur rreshti vjen nga një listim i filtruar, qoftë nga një kërkim me `query`.
hasMoreboolean: Nëse ka një faqe tjetër, nxjerrë nga `nextCursor` aty ku API-ja nuk e deklaron.
nextCursorstring | null: `nextPageToken`-i i API-së, për ta dërguar prapë si `cursor` për faqen pasuese, ose null kur nuk ka faqe tjetër. Një token bosh normalizohet në null, ndaj një kontroll falsy dhe një kontroll për null pajtohen.