Baza e njohurive

REST API

Një API HTTP e dokumentuar me çelësa që lëshohen, kufizohen në shtrirje dhe revokohen.

Hollësi

E ndezur, kudo. API-ja shërben 104 operacione të dokumentuara në 68 shtigje (email-et, bisedat, draftet, etiketat, kontaktet, audiencat, domenet, shabllonet, rregullat, rolet, anëtarët, cilësimet, kalendari, gjurmimi, webhook-et dhe llogaria) pas një dokumenti OpenAPI 3.1 të fiksuar që mund ta lexoni pa çelës te GET /openapi.json. Aksesi përcaktohet nga çelësi i hapësirës së punës që lëshoni te Cilësimet.
Qëndrueshmëria për të cilën dikur pritej kjo tashmë është bërë. Një dërgim shkruan një rresht para se të nisë çfarëdo gjëje, me një id publike të formës msg_ e ndjekur nga 24 shifra heksadecimale, dhe GET /emails/{id} e zgjidh atë, bashkë me /events për gjurmën për çdo marrës dhe /tracking për hapjet e klikimet. Një Idempotency-Key prej 1–255 karakteresh pretendohet ndaj një indeksi unik mbi çelësin dhe çelësin tuaj API së bashku, ndaj një riprovë pas një skadence kohore kthen rezultatin e parë me Idempotency-Replayed: true në vend që të dërgojë dy herë. Një dërgim me çelës përgjigjet 200 sapo të jetë stabilizuar dhe 202 ndërsa është ende në radhë ose i planifikuar.
Çelësat krijohen, kufizohen në shtrirje, rrotullohen dhe revokohen te Cilësimet → Çelësat API. Çdo çelës që lëshon konsola është një oe_live_. Prefiksi oe_test_ kuptohet nga verifikuesi dhe nga rruga e dërgimit, ku një dërgim në modalitet testi regjistrohet dhe raportohet si i dërguar pa mbërritur kurrë te një transport, por ende asgjë nuk mund të krijojë një të tillë, dhe ofrimi i kësaj mundësie para se transporti bosh të qëndrojë mbi Durable Object-in do t'ju jepte një çelës testi që dërgon vërtet. Një çelës mban një shtrirje dërgimi deri në 25 domene të plota dhe 50 adresa të veçanta, ku një domen i plotë mbulon edhe adresat që i shtohen më vonë, një skadencë opsionale midis 1 dhe 3650 ditësh, dhe opsionalisht një rol. Roli është një tavan dhe jo një dhënie e dytë lejesh: GET /ping kthen si shtrirjet e lejeve mbi çelës, ashtu edhe ato që i la roli, ndaj një 403 për një shtrirje që çelësi juaj e emërton qartë ka një shkak të dukshëm. Revokimi është një përditësim dhe jo një fshirje, ndaj një thirrjeje të mëvonshme i thuhet revoked_api_key në vend që thjesht të dështojë autentikimi. Rrotullimi ruan gjithçka të çelësit përveç sekretit: id-ja, shtrirjet e lejeve, shtrirja e dërgimit dhe historiku i kërkesave vazhdojnë, sekreti i vjetër vdes në çastin që krijohet i riu, dhe një çelës që mban keys:write mund ta rrotullojë vetveten përmes API-së. Të njëjtat veprime list, rotate, revoke dhe enable janë edhe në serverin MCP për këdo roli i të cilit mund të menaxhojë çelësa.
Çfarë mungon vërtet: API-ja nuk ka një endpoint të vetin për ngarkime. Bashkëngjitjet inline shkojnë si base64 nën një kufi të përgjithshëm prej 5 MB, ndërsa një skedar më i madh dërgohet duke emërtuar me id-në e tij një skedar që ndodhet tashmë në hapësirën e punës, i cili udhëton si lidhje shkarkimi. Kthimet trajtohen te kutia postare dhe jo te regjistri i dërgimeve: një raport dorëzimi analizohet, përputhet me origjinalin përmes Message-ID, etiketohet te biseda dhe dërgohet si webhook email.bounced, por asgjë nuk shkruan mbrapsht te rreshti i dërgimit, statusi i të cilit nuk ka gjendje bounced, ndaj përmes GET /emails një mesazh i kthyer lexohet ende si i dërguar. As posta e dërguar nga hartuesi i aplikacionit nuk shfaqet te GET /emails, sepse hartuesi nuk shkruan përmes së njëjtës rrugë dërgimi.