Çelësat, anëtarët dhe rolet

Këto komanda vendosin kush dhe çfarë mund ta arrijë hapësirën e punës. openemail keys menaxhon çelësat API dhe lexon çfarë bëri secili, openemail members menaxhon njerëzit në hapësirën e punës dhe ftesat e tyre, dhe openemail roles përcakton çfarë mund të bëjë një anëtar ose një çelës. openemail me përshkruan çelësin ose hyrjen me të cilën po thërrisni, dhe openemail languages liston gjuhët që pranon një dërgim i përkthyer. Kutitë e përkohshme nuk kanë nevojë fare për hyrje: openemail temp është mënyra e përditshme për të përdorur një të tillë, dhe openemail temp-mail është çdo thirrje e API-t pas saj. openemail api arrin çdo endpoint që nuk e arrijnë komandat e tjera.

• —Një komandë çelësi merr id-në e çelësit, 24 karakteret hex pas oe_live_, siç e tregon keys list. Një komandë anëtari merr id-në e llogarisë, userId te members list, kurrë një adresë emaili. Një komandë roli merr një id role_ nga roles list, sepse rolet nuk kërkohen sipas emrit.
• —Hapësirat e emrave u përgjigjen edhe key, member, role, language dhe tempMail. Pseudonimet e zakonshme të foljeve funksionojnë, si ls, show, new, edit dhe rm. Te members, foljet e së cilës janë add dhe remove, new dhe create çojnë te add, dhe rm, del dhe delete çojnë te remove.
• —openemail <command> --help liston çdo argument dhe flamur me llojin e tij, fushëveprimin që i duhet thirrjes, metodën dhe shtegun, dhe çfarë kthehet. Shtoni --json për të njëjtën faqe si të dhëna.

Leximi i çelësave kërkon keys:read, dhe çdo ndryshim kërkon keys:manage. Një hyrjeje me shfletues nuk i jepet kurrë keys:write ose keys:manage, ndaj krijimi, ndryshimi, rrotullimi, revokimi dhe fshirja e çelësave kërkojnë një çelës API që ka keys:manage, ose aplikacionin web (openemail open api-keys). Një hyrje me shfletues me keys:read lexon çelësat vetëm për pronarin e hapësirës së punës, dhe hyrja e një anëtari refuzohet me 403 owner_only.

• —keys create, keys rotate dhe me rotate shtypin sekretin e çelësit, te token, një herë, dhe CLI pastaj paralajmëron se nuk tregohet më kurrë. Çdo lexim tregon në vend të tij maskedKey.
• —Nëse lihen jashtë, një çelës i ri mban vetëm emails:send, dhe merr rolin, fushëveprimin e dërgimit dhe skadimin e çelësit që e krijon. --domain-allowlist dhe --address-allowlist caktojnë në emër të kujt mund të dërgojë, dhe --expires-in-minutes merr nga 5 deri në 5,256,000, që janë dhjetë vjet.
• —Një çelës nuk krijon dhe nuk arrin kurrë një çelës më të gjerë se vetja. Fushëveprimet, roli, skadimi, mënyra dhe fushëveprimi i dërgimit duhet të qëndrojnë të gjitha brenda çelësit që thërret, përndryshe thirrja refuzohet me 403 beyond_caller_authority, dhe param emërton atë që ishte tepër e gjerë. Një çelës i ngushtuar në disa domene ose adresa sheh vetëm çelësat brenda fushëveprimit të vet të dërgimit, dhe çdo tjetër jep 404.
• —keys update zëvendëson atë që dërgoni: --scopes, --address-allowlist dhe --domain-allowlist marrin secili gjithë listën e re, dhe një flamur që e lini jashtë mbetet siç ishte. --no-enabled e fik një çelës, ndaj çdo thirrje me të refuzohet me inactive_api_key, dhe --enabled e rikthen saktësisht. Kështu ndalet një çelës në një mënyrë që mund ta zhbëni.
• —keys revoke është përgjithmonë: çelësi nuk mund të ndizet më, të rrotullohet ose të ndryshohet. keys delete heq vetëm një çelës të revokuar, dhe çdo tjetër refuzohet me 409 not_revoked. Regjistri i kërkesave dhe aktiviteti i një çelësi të fshirë mbeten, nën Çelës i fshirë.
• —keys rotate nuk ka dritare mbivendosjeje, ndaj sekreti i vjetër pushon së punuari në çastin që kthehet i riu. Kur çelësi është ai që përdor profili juaj i ruajtur, CLI e ruan sekretin e ri në atë profil, që të vazhdojë të punojë. Një çelës nga OPENEMAIL_API_KEY ose --api-key nuk mund të ruhet, ndaj CLI ju thotë ta ruani tokenin e ri kudo që mbahej çelësi i vjetër.

Regjistri i kërkesave regjistron çdo thirrje që bëri një çelës: metodën, shtegun, statusin, kodin e gabimit, kohëzgjatjen, IP-në dhe user agent-in, kurrë një trup ose një query string. Asgjë nuk krasitet, ndaj shkon deri te thirrja e parë e një çelësi, dhe thirrjet e bëra me një hyrje me shfletues nuk janë në të. Regjistri i aktivitetit regjistron çdo ndryshim të një çelësi, dhe çdo thirrje që paraqiti çelësin dhe u refuzua, si auth_failed, me atë që bëri çdo ndryshim te actor.

• —list-requests dhe list-activity lexojnë një çelës. list-workspace-requests dhe list-workspace-activity lexojnë çdo çelës që mund të shihni, ose deri në 50 që emërton --key-ids, përfshirë çelësat e fshirë.
• —--since dhe --until mbajnë një dritare kohore dhe marrin një kohë ISO 8601 si 2026-09-01T00:00:00Z. --failed-only mban thirrjet që morën përgjigje me status 400 ose më shumë.

openemail me get është komanda e parë që duhet ekzekutuar kur një thirrje refuzohet. Nuk kërkon fushëveprim, ndaj çdo çelës ose hyrje e vlefshme mund ta përshkruajë veten.

• —scopes është ajo që kredenciali mund të bëjë tani: fushëveprimet me të cilat u krijua, të shkurtuara nga roli nën të cilin u lëshua, të llogaritura në çdo kërkesë. grantedScopes është ajo me të cilën u krijua, dhe roleId emërton rolin. Një fushëveprim që është te grantedScopes dhe mungon te scopes u hoq nga roli. Kjo është arsyeja e zakonshme për një 403 insufficient_scope te një çelës që duket se e ka fushëveprimin, dhe zgjidhja është të ndryshoni rolin në vend që të krijoni një çelës tjetër.
• —domainAllowlist dhe addressAllowlist tregojnë në emër të kujt mund të dërgojë. Të dyja null do të thotë çdo adresë që zotëron hapësira e punës.
• —Me një hyrje me shfletues përshkruan hyrjen: object është oauth_token, clientId emërton aplikacionin e lidhur të kësaj CLI-je, dhe expiresAt është kur mbaron miratimi juaj, ose null kur nuk mbaron kurrë.
• —me ping përgjigjet ok: true me të njëjtin detaj fushëveprimesh por pa listat e lejimit, gjë që i përshtatet një kontrolli gjendjeje. Një çelës i revokuar, i skaduar, i fikur ose i shkruar gabim dështon me një 401 dhe kodin e daljes 3.
• —me rotate i jep çelësit me të cilin po thërrisni një sekret të ri. Kërkon keys:write, që një hyrje me shfletues nuk e ka kurrë, ndaj kërkon një çelës API. Gjithçka tjetër e çelësit mbetet, sekreti i vjetër pushon së punuari menjëherë, dhe një profil i ruajtur merr të riun, si me keys rotate. Një përgjigje e humbur mund ta lërë çelësin me një sekret që nuk e pa askush, dhe atëherë ai ka nevojë për një të ri nga aplikacioni web.
• —openemail whoami tregon të njëjtën përgjigje të formatuar për njerëz.

openemail languages list shtyp gjithë tabelën e gjuhëve në një përgjigje, rreth dyqind rreshta, me kodin, emrin në anglisht, emrin e vet, flamurin e çdo gjuhe dhe nëse shkruhet nga e djathta në të majtë. Kodi, emri në anglisht ose emri i vet funksionojnë të gjithë si objektiv i një dërgimi të përkthyer. Kërkon një hyrje por asnjë fushëveprim. openemail ai languages shtyp të njëjtën tabelë me një flamur --search, dhe pa hyrje shtyp tabelën që vjen me CLI-në.

Një anëtar mban dy gjëra që nuk bashkohen kurrë. Roli i tij tregon çfarë mund të bëjë, dhe të drejtat e tij mbi adresat dhe domenet tregojnë me cilën postë mund ta bëjë, secila e drejtë me qasjen e vet: member lexon dhe dërgon, dhe viewer vetëm lexon. Një dërgim kërkon të dyja, ndaj një rol me emails:send dhe një e drejtë viewer mbi një adresë ende nuk mund të dërgojë prej saj. Një domen i tërë mbulon çdo adresë në të, përfshirë ato të krijuara më vonë.

• —members list e vendos pronarin e hapësirës së punës të parin, të shënuar isOwner, ndaj lëreni atë rresht jashtë kur numëroni vendet. Pronari ka çdo leje dhe nuk mund të ftohet, ndryshohet ose hiqet, dhe as dikush që është tashmë në hapësirën e punës nuk mund të ftohet sërish: të dyja japin 422 member_is_owner.
• —Njerëzit që kanë të drejta mbi adresa por nuk iu dha kurrë një rol kthehen me implied: true, dhe roli i tyre nxirret nga të drejtat e tyre. members update u jep një rol të vërtetë.
• —members add dërgon një ftesë, edhe te dikush që ka tashmë një llogari. Asgjë nuk jepet derisa të pranojë, dhe atëherë saktësisht roli, adresat dhe domenet që mbart ftesa. Ftesa sërish e së njëjtës adresë brenda dhjetë minutave jep 409 invitation_too_soon, dhe pas kësaj rifreskon ftesën në pritje në vend që të dërgojë një të dytë.
• —resend-invitation dërgon një lidhje të re të vlefshme për 14 ditë të tjera dhe e tërheq të vjetrën, gjë që rinovon edhe një ftesë të skaduar. revoke-invitation tërheq një ftesë, dhe një ftesë që është pranuar tashmë jep 409 invitation_accepted, ndaj hiqeni anëtarin në vend të kësaj.
• —members update ndryshon rolin dhe asgjë tjetër. grant-address jep një adresë ose ndryshon qasjen ndaj saj, ndaj ekzekutimi sërish me një --access tjetër e ndryshon të drejtën në vend që të shtojë një të dytë. revoke-address merr prapa një adresë dhe i lë të tjerat. Revokimi i të drejtës së fundit të një anëtari të nënkuptuar e heq atë nga hapësira e punës.
• —members remove i jep fund qasjes së dikujt në hapësirën e punës, anëtarësisë dhe çdo të drejte, dhe raporton te addressesRevoked sa të drejta adresash u hoqën. Llogaria e tij dhe posta që ka dërguar nuk preken.

Një rol është gjithashtu tavan për çelësat API të lëshuar nën të. Ajo që mund të bëjë një çelës janë fushëveprimet e veta të shkurtuara nga lejet e rolit të tij, të llogaritura në çdo kërkesë.

• —roles list tregon fillimisht rolet e paracaktuara, në rendin Owner, Admin, Member, Viewer, Developer dhe Billing, pastaj rolet e personalizuara sipas emrit. Një hapësirë pune mban deri në 24 role të personalizuara, dhe përtej kësaj roles create jep 422 role_limit_reached.
• —Një rol ruan edhe lejet që nënkuptohen nga lejet e tij, ndaj templates:write ruan edhe templates:read, dhe roles:write sjell roles:read dhe members:read. Lexojeni listën nga përgjigjja në vend që ta supozoni.
• —roles update --permissions zëvendëson gjithë listën, ndaj lexoni rolin, ndryshoni listën dhe dërgojeni të gjithën. --description null e pastron shënimin. Një ndryshim hyn në fuqi në thirrjen e radhës të çdo anëtari dhe çelësi që e mban rolin.
• —Çdo rol përveç Owner mund të riemërtohet, rishkruhet dhe fshihet, përfshirë ato të paracaktuarat, dhe një rol i paracaktuar i fshirë nuk kthehet. Roli i pronarit i përgjigjet një redaktimi me 409 role_immutable dhe një fshirjeje me 409 role_undeletable.
• —Për sa kohë ndonjë anëtar, çelës API ose ftesë në pritje mban një rol, roles delete kërkon --reassign-to me rolin që i merr ata, përndryshe refuzohet me 409 role_in_use. Çelësat e revokuar tregojnë ende rolin e tyre, ndaj një rol numri apiKeys i të cilit është 0 mund ta kërkojë përsëri. Përgjigjja raporton njerëzit reassigned dhe çelësat keysReassigned.
• —roles list-permissions liston gjithë fjalorin me një etiketë dhe një grup për secilën. Disa, si billing:write dhe workspace:manage, kthehen me scope: false: një rol mund t'i mbajë, por asnjë çelës nuk mundet.

Një kuti e përkohshme nuk kërkon llogari dhe as hyrje. Arrihet me tokenin e vet të kutisë, i cili nis me oe_inbox_ dhe kthehet një herë, kur krijohet kutia. Përdorni openemail temp në përditshmëri, dhe openemail temp-mail kur ju duhet një fushë ose një hap që temp nuk e tregon, si zgjatjet që kanë mbetur, një zgjatje, ose bajtet e një bashkëngjitjeje.

• —Të dyja e mbajnë tokenin në ~/.openemail/temp-mail.json, të lexueshëm vetëm nga ju. temp new dhe temp-mail create e ruajnë, temp list tregon kutitë e krijuara në secilën mënyrë, dhe të dyja fshirjet e harrojnë. Një kuti e ruajtur mund të emërtohet me adresën e saj kudo që një komandë kërkon id-në e saj.
• —Për një kuti që nuk e krijoi kjo CLI, jepeni tokenin me --inbox-token. Pa token të ruajtur ose të dhënë, komanda ndalet me kodin e daljes 3 para se të dërgohet ndonjë gjë.
• —Dy komandat e krijimit i emërtojnë flamujt ndryshe: temp new merr --name, --domain dhe --ttl, dhe temp-mail create merr --local-part, --domain dhe --ttl-minutes. Një local-part ka nga 3 deri në 32 shkronja, shifra, pika, viza ose nënvija, duke nisur dhe mbaruar me shkronjë ose shifër, dhe emra si postmaster refuzohen. Qiraja zgjat nga 1 deri në 1440 minuta, 60 si parazgjedhje.
• —Çdo adresë IP mund të krijojë 6 kuti në orë dhe 30 në ditë, dhe e radhës jep 429 too_many_inboxes, kodi i daljes 8. Zgjatja e një kutie që e keni tashmë nuk numërohet, ndaj temp-mail extend është përgjigjja për atë kufi.
• —temp-mail extend shton deri në një orë, kurrë përtej 24 orëve pas krijimit të kutisë, dhe të shumtën 23 herë. Lexoni extensionsLeft nga përgjigjja. Kur arrin 0, jep 409 extension_limit përgjithmonë.
• —temp-mail list-messages lexon nga 1 deri në 50 mesazhe për faqe, 50 si parazgjedhje, secili me një snippet teksti të thjeshtë deri në 400 karaktere që shpesh mban një kod njëpërdorimsh. Asgjë përtej një faqeje nuk hidhet, dhe --all përshkon çdo faqe.
• —Leximi i një mesazhi me temp read, temp-mail get-message ose temp-mail list-attachments e shënon atë si të parë. Një trup mbi 2 MB shkurtohet, gjë që e tregon truncated, dhe një bashkëngjitje mbi 8 MB nuk u mbajt kurrë, ndaj content i saj është null.
• —Fshirja e një kutie e fshin menjëherë postën e saj, por adresa mbetet e rezervuar deri 7 ditë pasi do të mbaronte qiraja e saj, dhe kërkimi i saj sërish para asaj kohe jep 409 address_taken.

openemail api <method> <path> dërgon një kërkesë përmes të njëjtit transport si çdo komandë tjetër, ndaj vlejnë profili ose çelësi juaj, rinovimi i tokenit, kodet e verifikimit dhe konfirmimet. Një shteg më vete është një GET, dhe një përgjigje JSON shtypet e formatuar. openemail api /keys/self është thirrja pas me get.

• —-d, --data merr trupin si JSON në rresht, nga një skedar me @path, ose nga stdin me -. -q, --query dhe -H, --header marrin key=value dhe mund të përsëriten, dhe -o, --out e ruan përgjigjen në një skedar ashtu siç erdhi.
• —Një DELETE, dhe çdo thirrje që një komandë burimi do ta kërkonte për konfirmim, si revokimi ose rrotullimi i një çelësi, ju kërkon së pari konfirmim, dhe pa mbikëqyrje kërkon --yes.
• —Një kërkesë e dështuar shtyp gabimin e API-t dhe del me kodin përkatës.

Hapësira e emrave security nuk listohet te openemail --help, sepse e drejton openemail verify. Foljet e saj step-up-status, begin-step-up dhe verify-step-up janë thirrjet që bën verify: verify --status lexon statusin, dhe verify kërkon një kod, jua kërkon ta shkruani dhe e kontrollon. Ato ekzistojnë për një hyrje me shfletues. Me një çelës API secila refuzohet me 400 step_up_not_applicable, dhe openemail verify thotë se një çelës nuk ka kurrë nevojë për kod.

openemail keys create --name 'Billing sender' --scopes emails:send \  --domain-allowlist billing.acme.com --expires-in-minutes 129600 --json \  | jq -r .token | openemail login --with-token --profile billingopenemail whoami --profile billing

Ekzekutojeni me një çelës API që ka keys:manage, për shembull përmes OPENEMAIL_API_KEY. Sekreti shkon nga përgjigjja drejt e në një profil të ri, ndaj nuk shfaqet kurrë në ekran ose në një skedar. Çelësi mund të dërgojë vetëm nga billing.acme.com, dhe skadon pas 90 ditësh.

openemail keys list --all | jq -r 'select(.status != "active") | [.name, .status, .lastUsedAt] | @tsv'openemail keys list-workspace-requests --failed-only --since 2026-09-26T00:00:00Z --all \  | jq -r '[.createdAt, .keyName, .status, .errorCode, .method, .path] | @tsv'

id=4c1b257a66287fd113bd89d0openemail keys update "$id" --no-enabledopenemail keys list-activity "$id" --since 2026-09-27T00:00:00Z --all | jq -r 'select(.type == "auth_failed") | .createdAt'openemail keys revoke "$id" --reason 'Contractor offboarded' --yesopenemail keys delete "$id" --yes

Fikja e çelësit së pari mund të zhbëhet me --enabled. Çdo thirrje që e paraqet ende refuzohet dhe shfaqet në aktivitetin e tij si auth_failed, gjë që ju tregon çfarë varet ende prej tij. Revokimi nuk mund të zhbëhet, dhe vetëm një çelës i revokuar mund të fshihet.

openemail roles list-permissions --json | jq -r '.[] | [.group, .id, .label] | @tsv'role=$(openemail roles create --name Support --permissions threads:write,emails:send,templates:read \  --description 'Answers help@ and nothing else.' --json | jq -r .id)openemail members add --email [email protected] --role-id "$role" \  --domain-ids 93542ff8-2baa-4f2f-841d-5ceaa074ab0d --access memberopenemail members list-invitations

Roli kthehet duke mbajtur gjithashtu threads:read dhe emails:read, sepse lejet që emërton i nënkuptojnë ato. Sam merr rolin dhe gjithë domenin vetëm pasi ta pranojë. Me një hyrje me shfletues, members add kërkon së pari një kod verifikimi.

old=role_8b1f4c2e9a7d3b60e5f1a2c4new=role_2c7e9a1f4b8d3e60c5a7f1b9user=$(openemail members list --all | jq -r 'select(.email == "[email protected]") | .userId')openemail members update "$user" --role-id "$new"openemail roles get "$old" --json | jq '{name, members, apiKeys}'openemail roles delete "$old" --reassign-to "$new" --dry-runopenemail roles delete "$old" --reassign-to "$new" --yes

members dhe apiKeys numërohen kur i kërkoni, ndaj tregojnë çfarë do të zhvendosë fshirja. Ekzekutimi provë shtyp DELETE me reassignTo në query-n e tij pa e dërguar. Me një hyrje me shfletues, përditësimi dhe fshirja kërkojnë secila një kod verifikimi, ndaj ekzekutoni fillimisht openemail verify kur këtë e bën një skript.

address=$(openemail temp new --ttl 15)openemail send --from [email protected] --to "$address" --subject 'Delivery check' --text 'Your code is 482913' --yesopenemail temp watch "$address" --first --json | jq -r .snippet | grep -oE '[0-9]{6}'openemail temp delete "$address" --yes

temp new shtyp vetëm adresën, ndaj përshtatet në një variabël shell-i, dhe temp watch --first ndalet te mesazhi i parë. Drejtojeni një formular regjistrimi te adresa në vend të openemail send për të kapur në të njëjtën mënyrë kodin e tij të konfirmimit.

• —Një hyrje ose çelës pa fushëveprimin ndalet me kodin e daljes 4, emërton fushëveprimin që mungon dhe tregon si ta merrni.
• —Këto kërkojnë konfirmim: keys delete, rotate dhe revoke, me rotate, roles delete, members remove, revoke-address dhe revoke-invitation, temp delete, si edhe temp-mail delete dhe delete-message. Përgjigjja jo del me kodin 10 dhe nuk ndryshon asgjë. Pa mbikëqyrje dhe pa --yes, ndalen me kodin e daljes 2 para se të dërgohet ndonjë gjë.
• —Me një hyrje me shfletues, roles update dhe roles delete, si edhe members add, update, remove, grant-address dhe revoke-address, kërkojnë gjithashtu një kod verifikimi, përveç nëse kjo hyrje ka verifikuar një kod në 60 minutat e fundit. --yes nuk e kapërcen kurrë, dhe pa mbikëqyrje askush nuk mund ta shkruajë, ndaj komanda ndalet me kodin e daljes 4. Ekzekutoni fillimisht openemail verify. Një çelësi API nuk i kërkohet kurrë.
• —--dry-run shtyp kërkesën që do të dërgonte një ndryshim, me trupin e saj, dhe del me kodin 0 pa e dërguar dhe pa ju kërkuar konfirmim.
• —Një listë lexon një faqe. --limit merr nga 1 deri në 100 dhe serveri dërgon 25 kur lihet jashtë, përveç te temp-mail list-messages, që merr nga 1 deri në 50 dhe dërgon 50. --cursor merr nextCursor e faqes së mëparshme. --all lexon çdo faqe, --max <n> ndalet pas aq elementeve, dhe --ndjson, ose --all në një pipe, shtyp një objekt JSON për rresht. Me --json, një listë shtyp një dokument të vetëm { items, hasMore, nextCursor }.
• —roles list-permissions, languages list, temp-mail list-domains dhe temp-mail list-attachments kthejnë gjithçka njëherësh, si një array i thjeshtë, pa faqe.
• —Një refuzim del me kodin e statusit të vet: 3 për një 401, si një çelës i revokuar, 4 për një 403, si beyond_caller_authority ose owner_only, 5 për një 404, 6 për një 409, si not_revoked, role_in_use ose invitation_too_soon, 7 për një 400 ose një 422, si member_is_owner ose role_limit_reached, dhe 8 për një 429, si too_many_inboxes.
• —Një ndryshim që do të bënte diçka dy herë nuk riprovohet kurrë pas një dështimi rrjeti: keys create dhe rotate, me rotate, roles create dhe delete, members add, remove, revoke-address dhe resend-invitation, si edhe temp-mail create, extend, delete dhe delete-message. Kontrolloni para se ta ekzekutoni sërish njërën. Leximet, dhe ndryshimet që japin të njëjtin rezultat dy herë, si keys update, keys revoke, roles update, members update dhe grant-address, riprovohen vetë.