कुंजियाँ, सदस्य और भूमिकाएँ

ये कमांड तय करती हैं कि कौन और क्या वर्कस्पेस तक पहुँच सकता है। openemail keys API कुंजियाँ प्रबंधित करता है और पढ़ता है कि हर एक ने क्या किया, openemail members वर्कस्पेस के लोगों और उनके आमंत्रणों को प्रबंधित करता है, और openemail roles तय करता है कि कोई सदस्य या कुंजी क्या कर सकती है। openemail me उस कुंजी या साइन-इन का ब्योरा देता है जिससे आप कॉल कर रहे हैं, और openemail languages उन भाषाओं की सूची देता है जिन्हें अनुवाद वाला भेजना स्वीकार करता है। डिस्पोज़ेबल इनबॉक्स को साइन-इन की बिल्कुल ज़रूरत नहीं: openemail temp रोज़ इस्तेमाल का तरीका है, और openemail temp-mail उसके पीछे के API की हर कॉल है। openemail api किसी भी ऐसे एंडपॉइंट तक पहुँचता है जहाँ दूसरी कमांड नहीं पहुँचतीं।

• —कुंजी कमांड कुंजी ID लेती है, यानी oe_live_ के बाद के 24 hex अक्षर, जैसा keys list दिखाता है। सदस्य कमांड अकाउंट ID लेती है, members list में userId, कभी ईमेल पता नहीं। भूमिका कमांड roles list से मिली role_ ID लेती है, क्योंकि भूमिकाओं को नाम से नहीं ढूँढा जा सकता।
• —नेमस्पेस key, member, role, language और tempMail से भी चलते हैं। सामान्य वर्ब उपनाम काम करते हैं, जैसे ls, show, new, edit और rm। members में, जिसके वर्ब add और remove हैं, new और create से add चलता है, और rm, del और delete से remove।
• —openemail <command> --help हर आर्ग्युमेंट और फ़्लैग की सूची देता है, उसके टाइप, कॉल के ज़रूरी स्कोप, मेथड और पाथ, और जो लौटता है उसके साथ। वही पेज डेटा के रूप में पाने के लिए --json जोड़ें।

कुंजियाँ पढ़ने के लिए keys:read चाहिए, और हर बदलाव के लिए keys:manage। ब्राउज़र साइन-इन को कभी keys:write या keys:manage नहीं मिलता, इसलिए कुंजियाँ बनाने, बदलने, रोटेट करने, रद्द करने और हटाने के लिए keys:manage वाली API कुंजी या वेब ऐप (openemail open api-keys) चाहिए। keys:read वाला ब्राउज़र साइन-इन सिर्फ़ वर्कस्पेस के मालिक के लिए कुंजियाँ पढ़ता है, और सदस्य का साइन-इन 403 owner_only के साथ अस्वीकार होता है।

• —keys create, keys rotate और me rotate कुंजी का सीक्रेट token में एक बार प्रिंट करती हैं, और फिर CLI चेतावनी देती है कि यह फिर कभी नहीं दिखेगा। हर पढ़ने में इसकी जगह maskedKey दिखता है।
• —छोड़ दिए जाएँ तो नई कुंजी के पास सिर्फ़ emails:send होता है, और वह बनाने वाली कुंजी की भूमिका, भेजने का दायरा और समय-सीमा लेती है। --domain-allowlist और --address-allowlist तय करते हैं कि वह किन पतों से भेज सकती है, और --expires-in-minutes 5 से 5,256,000 लेता है, यानी दस साल।
• —कोई कुंजी अपने से ज़्यादा दायरे वाली कुंजी न कभी बनाती है न उस तक पहुँचती है। स्कोप, भूमिका, समय-सीमा, मोड और भेजने का दायरा, सभी कॉल करने वाली कुंजी के भीतर होने चाहिए, वरना कॉल 403 beyond_caller_authority के साथ अस्वीकार होती है, और param बताता है कि क्या ज़्यादा चौड़ा था। कुछ डोमेन या पतों तक सीमित कुंजी सिर्फ़ अपने भेजने के दायरे के भीतर की कुंजियाँ देखती है, और बाकी कोई भी 404 है।
• —keys update वही बदलती है जो आप भेजते हैं: --scopes, --address-allowlist और --domain-allowlist हर एक पूरी नई सूची लेता है, और जो फ़्लैग आप छोड़ देते हैं वह जैसा था वैसा रहता है। --no-enabled कुंजी को बंद करता है, जिससे उसके साथ हर कॉल inactive_api_key के साथ अस्वीकार होती है, और --enabled उसे ठीक पहले जैसा लौटा देता है। यह कुंजी को ऐसे रोकता है जिसे पलटा जा सके।
• —keys revoke हमेशा के लिए है: कुंजी को फिर कभी चालू, रोटेट या बदला नहीं जा सकता। keys delete सिर्फ़ रद्द की गई कुंजी हटाती है, और बाकी कोई भी 409 not_revoked के साथ अस्वीकार होती है। हटाई गई कुंजी का अनुरोध लॉग और गतिविधि "हटाई गई कुंजी" के नाम से बने रहते हैं।
• —keys rotate में कोई साझा अवधि नहीं होती, इसलिए नया सीक्रेट लौटते ही पुराना काम करना बंद कर देता है। जब यह वही कुंजी हो जिसे आपकी सहेजी प्रोफ़ाइल इस्तेमाल करती है, तो CLI नया सीक्रेट उस प्रोफ़ाइल में सहेजती है, ताकि वह काम करती रहे। OPENEMAIL_API_KEY या --api-key से मिली कुंजी सहेजी नहीं जा सकती, इसलिए CLI आपसे कहती है कि नया टोकन वहीं रखें जहाँ पुरानी कुंजी रखी थी।

अनुरोध लॉग किसी कुंजी की हर कॉल दर्ज करता है: मेथड, पाथ, स्थिति, एरर कोड, अवधि, IP और यूज़र एजेंट, कभी बॉडी या क्वेरी स्ट्रिंग नहीं। कुछ भी हटाया नहीं जाता, इसलिए यह कुंजी की पहली कॉल तक जाता है, और ब्राउज़र साइन-इन से की गई कॉल इसमें नहीं होतीं। गतिविधि लॉग कुंजी के हर बदलाव को दर्ज करता है, और हर उस कॉल को जिसने कुंजी दिखाई और अस्वीकार हुई, auth_failed के रूप में, और actor में यह कि हर बदलाव किसने किया।

• —list-requests और list-activity एक कुंजी पढ़ती हैं। list-workspace-requests और list-workspace-activity हर वह कुंजी पढ़ती हैं जो आपको दिखती है, या --key-ids में बताई 50 तक कुंजियाँ, हटाई गई कुंजियों सहित।
• —--since और --until एक अवधि रखते हैं और 2026-09-01T00:00:00Z जैसा ISO 8601 समय लेते हैं। --failed-only सिर्फ़ वे कॉल रखता है जिनका जवाब 400 या उससे ऊपर की स्थिति के साथ आया।

कोई कॉल अस्वीकार होने पर सबसे पहले openemail me get चलाएँ। इसे किसी स्कोप की ज़रूरत नहीं, इसलिए कोई भी मान्य कुंजी या साइन-इन अपना ब्योरा दे सकता है।

• —scopes वह है जो क्रेडेंशियल अभी कर सकता है: जिन स्कोप के साथ वह बना था, उन्हें उस भूमिका से छाँटा गया जिसके तहत वह जारी हुआ, और यह हर अनुरोध पर तय होता है। grantedScopes वह है जिसके साथ वह बना था, और roleId भूमिका का नाम बताता है। जो स्कोप grantedScopes में है पर scopes में नहीं, उसे भूमिका ने हटाया है। स्कोप रखती दिखने वाली कुंजी पर 403 insufficient_scope की यही आम वजह है, और इसका हल दूसरी कुंजी बनाना नहीं, भूमिका बदलना है।
• —domainAllowlist और addressAllowlist बताते हैं कि यह किन पतों से भेज सकता है। दोनों null का मतलब है वर्कस्पेस का कोई भी पता।
• —ब्राउज़र साइन-इन के साथ यह साइन-इन का ब्योरा देता है: object oauth_token होता है, clientId इस CLI के कनेक्टेड ऐप का नाम बताता है, और expiresAt आपकी मंज़ूरी ख़त्म होने का समय है, या null जब वह कभी ख़त्म न हो।
• —me ping वही स्कोप ब्योरा देते हुए ok: true जवाब देता है, पर अनुमति सूचियों के बिना, जो हेल्थ चेक के लिए ठीक है। रद्द, समय-सीमा ख़त्म, बंद या ग़लत टाइप की गई कुंजी 401 और एग्ज़िट कोड 3 के साथ विफल होती है।
• —me rotate उस कुंजी को नया सीक्रेट देता है जिससे आप कॉल कर रहे हैं। इसे keys:write चाहिए, जो ब्राउज़र साइन-इन के पास कभी नहीं होता, इसलिए इसे API कुंजी चाहिए। कुंजी की बाकी हर चीज़ वैसी ही रहती है, पुराना सीक्रेट तुरंत काम करना बंद कर देता है, और सहेजी प्रोफ़ाइल को नया मिल जाता है, जैसे keys rotate में। जवाब खो जाने पर कुंजी ऐसे सीक्रेट के साथ रह सकती है जिसे किसी ने नहीं देखा, और तब उसे वेब ऐप से नया सीक्रेट चाहिए।
• —openemail whoami वही जवाब लोगों के पढ़ने लायक रूप में दिखाता है।

openemail languages list पूरी भाषा तालिका एक ही जवाब में प्रिंट करता है, लगभग दो सौ पंक्तियाँ, हर भाषा के कोड, अंग्रेज़ी नाम, अपने नाम, झंडे और क्या वह दाएँ से बाएँ लिखी जाती है, इसके साथ। अनुवाद वाले भेजने के लक्ष्य के रूप में कोड, अंग्रेज़ी नाम या अपना नाम, सभी काम करते हैं। इसे साइन-इन चाहिए पर कोई स्कोप नहीं। openemail ai languages वही तालिका --search फ़्लैग के साथ प्रिंट करता है, और साइन आउट होने पर CLI के साथ आई तालिका प्रिंट करता है।

सदस्य के पास दो चीज़ें होती हैं जो कभी मिलाई नहीं जातीं। उनकी भूमिका बताती है कि वे क्या कर सकते हैं, और उनके पते और डोमेन के अधिकार बताते हैं कि किस मेल के साथ, हर अधिकार की अपनी पहुँच के साथ: member पढ़ता और भेजता है, और viewer सिर्फ़ पढ़ता है। भेजने के लिए दोनों चाहिए, इसलिए emails:send वाली भूमिका और किसी पते पर viewer अधिकार के साथ भी उस पते से भेजा नहीं जा सकता। पूरा डोमेन उस पर हर पते को कवर करता है, बाद में बने पतों को भी।

• —members list वर्कस्पेस के मालिक को सबसे पहले रखती है, isOwner के निशान के साथ, इसलिए सीटें गिनते समय वह पंक्ति छोड़ दें। मालिक के पास हर अनुमति होती है और उसे न आमंत्रित किया जा सकता है, न बदला, न हटाया, और वर्कस्पेस में पहले से मौजूद किसी को फिर से आमंत्रित नहीं किया जा सकता: दोनों 422 member_is_owner हैं।
• —जिन लोगों के पास पते के अधिकार हैं पर जिन्हें कभी भूमिका नहीं दी गई, वे implied: true के साथ लौटते हैं, और उनकी भूमिका उनके अधिकारों से अनुमानित होती है। members update उन्हें असली भूमिका देती है।
• —members add आमंत्रण भेजती है, उस व्यक्ति को भी जिसका पहले से अकाउंट है। जब तक वे स्वीकार न करें कुछ नहीं दिया जाता, और फिर ठीक वही भूमिका, पते और डोमेन जो आमंत्रण में हैं। दस मिनट के भीतर उसी पते को फिर आमंत्रित करना 409 invitation_too_soon है, और उसके बाद यह दूसरा भेजने के बजाय इंतज़ार कर रहे आमंत्रण को ताज़ा करता है।
• —resend-invitation 14 और दिनों के लिए मान्य नया लिंक भेजती है और पुराने को रिटायर कर देती है, जिससे समय-सीमा ख़त्म हुआ आमंत्रण भी नया हो जाता है। revoke-invitation आमंत्रण वापस लेती है, और पहले से स्वीकार हुआ आमंत्रण 409 invitation_accepted है, इसलिए इसके बजाय सदस्य को हटाएँ।
• —members update सिर्फ़ भूमिका बदलती है, और कुछ नहीं। grant-address एक पता देती है या उस पर पहुँच बदलती है, इसलिए दूसरे --access के साथ फिर चलाने पर दूसरा अधिकार नहीं जुड़ता, वही अधिकार बदल जाता है। revoke-address एक पता वापस लेती है और बाकी छोड़ देती है। अनुमानित सदस्य का आख़िरी अधिकार रद्द करने पर वह वर्कस्पेस से हट जाता है।
• —members remove किसी की वर्कस्पेस तक पहुँच, उनकी सदस्यता और हर अधिकार ख़त्म करती है, और addressesRevoked में बताती है कि पते के कितने अधिकार गए। उनका अकाउंट और उनकी भेजी मेल अछूते रहते हैं।

भूमिका उसके तहत जारी API कुंजियों की ऊपरी सीमा भी है। कुंजी क्या कर सकती है, यह उसके अपने स्कोप हैं जिन्हें उसकी भूमिका की अनुमतियों से छाँटा गया है, और यह हर अनुरोध पर तय होता है।

• —roles list पहले से बनी भूमिकाएँ सबसे पहले दिखाती है, Owner, Admin, Member, Viewer, Developer और Billing के क्रम में, फिर कस्टम भूमिकाएँ नाम से। एक वर्कस्पेस में 24 तक कस्टम भूमिकाएँ होती हैं, और उसके बाद roles create 422 role_limit_reached है।
• —भूमिका वे अनुमतियाँ भी सहेजती है जो उसकी अनुमतियों में निहित हैं, इसलिए templates:write templates:read भी सहेजता है, और roles:write साथ में roles:read और members:read लाता है। सूची मान न लें, जवाब से वापस पढ़ें।
• —roles update --permissions पूरी सूची बदल देती है, इसलिए भूमिका पढ़ें, सूची बदलें और पूरी भेजें। --description null नोट साफ़ करता है। बदलाव उस भूमिका वाले हर सदस्य और कुंजी की अगली कॉल पर लागू हो जाता है।
• —Owner को छोड़कर हर भूमिका का नाम बदला, उसे फिर से लिखा और हटाया जा सकता है, पहले से बनी भूमिकाएँ भी, और हटाई गई पहले से बनी भूमिका वापस नहीं आती। मालिक की भूमिका बदलाव पर 409 role_immutable और हटाने पर 409 role_undeletable लौटाती है।
• —जब तक किसी सदस्य, API कुंजी या इंतज़ार कर रहे आमंत्रण के पास कोई भूमिका है, roles delete को उन्हें संभालने वाली भूमिका के साथ --reassign-to चाहिए, वरना यह 409 role_in_use के साथ अस्वीकार होती है। रद्द कुंजियाँ भी अपनी भूमिका की ओर इशारा करती रहती हैं, इसलिए जिस भूमिका की apiKeys गिनती 0 है उसे भी इसकी ज़रूरत पड़ सकती है। जवाब reassigned लोग और keysReassigned कुंजियाँ बताता है।
• —roles list-permissions पूरी शब्दावली दिखाती है, हर एक के लेबल और समूह के साथ। कुछ, जैसे billing:write और workspace:manage, scope: false के साथ लौटती हैं: भूमिका इन्हें रख सकती है, पर कोई कुंजी नहीं।

डिस्पोज़ेबल इनबॉक्स को न अकाउंट चाहिए न साइन-इन। उस तक उसके अपने इनबॉक्स टोकन से पहुँचा जाता है, जो oe_inbox_ से शुरू होता है और इनबॉक्स बनने पर एक बार लौटता है। रोज़ के काम के लिए openemail temp इस्तेमाल करें, और openemail temp-mail तब जब आपको कोई ऐसा फ़ील्ड या चरण चाहिए जो temp नहीं दिखाता, जैसे बचे हुए विस्तार, विस्तार, या किसी अटैचमेंट के बाइट।

• —दोनों टोकन को ~/.openemail/temp-mail.json में रखते हैं, जिसे सिर्फ़ आप पढ़ सकते हैं। temp new और temp-mail create उसे सहेजती हैं, temp list दोनों तरह से बने इनबॉक्स दिखाती है, और दोनों तरह का हटाना उसे भूल जाता है। जहाँ भी कोई कमांड ID माँगे, वहाँ सहेजे इनबॉक्स को उसके पते से बताया जा सकता है।
• —जो इनबॉक्स इस CLI ने नहीं बनाया, उसके लिए टोकन --inbox-token से दें। कोई सहेजा या दिया गया टोकन न हो, तो कमांड कुछ भी भेजे जाने से पहले एग्ज़िट कोड 3 के साथ रुकती है।
• —दोनों बनाने वाली कमांड अपने फ़्लैग के नाम अलग रखती हैं: temp new --name, --domain और --ttl लेती है, और temp-mail create --local-part, --domain और --ttl-minutes लेती है। लोकल पार्ट 3 से 32 अक्षरों, अंकों, बिंदुओं, डैश या अंडरस्कोर का होता है, जो किसी अक्षर या अंक से शुरू और ख़त्म हो, और postmaster जैसे नाम अस्वीकार होते हैं। लीज़ 1 से 1440 मिनट की होती है, डिफ़ॉल्ट 60।
• —हर IP पता एक घंटे में 6 और एक दिन में 30 इनबॉक्स बना सकता है, और अगला 429 too_many_inboxes है, एग्ज़िट कोड 8। पहले से मौजूद इनबॉक्स को बढ़ाना गिना नहीं जाता, इसलिए इस सीमा का जवाब temp-mail extend है।
• —temp-mail extend एक घंटे तक जोड़ता है, इनबॉक्स बनने के 24 घंटे से आगे कभी नहीं, और ज़्यादा से ज़्यादा 23 बार। जवाब से extensionsLeft पढ़ें। 0 होने पर यह हमेशा के लिए 409 extension_limit है।
• —temp-mail list-messages हर पेज में 1 से 50 संदेश पढ़ती है, डिफ़ॉल्ट 50, हर एक 400 वर्णों तक के सादे टेक्स्ट snippet के साथ, जिसमें अक्सर एक बार का कोड होता है। पेज से आगे का कुछ भी छोड़ा नहीं जाता, और --all हर पेज से गुज़रता है।
• —temp read, temp-mail get-message या temp-mail list-attachments से संदेश पढ़ने पर वह देखा हुआ चिह्नित होता है। 2 MB से बड़ी बॉडी काट दी जाती है, जो truncated बताता है, और 8 MB से बड़ा अटैचमेंट कभी रखा ही नहीं गया, इसलिए उसका content null है।
• —इनबॉक्स हटाने पर उसकी मेल तुरंत मिट जाती है, पर पता उसकी लीज़ ख़त्म होने के 7 दिन बाद तक आरक्षित रहता है, और उससे पहले उसे फिर माँगना 409 address_taken है।

openemail api <method> <path> हर दूसरी कमांड वाले ही ट्रांसपोर्ट से एक अनुरोध भेजता है, इसलिए आपकी प्रोफ़ाइल या कुंजी, टोकन का नवीनीकरण, सत्यापन कोड और पुष्टियाँ सब लागू होते हैं। अकेला पाथ एक GET है, और JSON जवाब फ़ॉर्मैट होकर प्रिंट होता है। openemail api /keys/self me get के पीछे की कॉल है।

• —-d, --data बॉडी को इनलाइन JSON के रूप में, @path से फ़ाइल से, या - से stdin से लेता है। -q, --query और -H, --header key=value लेते हैं और दोहराए जा सकते हैं, और -o, --out जवाब को जैसा आया वैसा फ़ाइल में सहेजता है।
• —DELETE, और हर वह कॉल जिसकी पुष्टि कोई रिसोर्स कमांड माँगती, जैसे कुंजी रद्द या रोटेट करना, पहले पुष्टि माँगती है, और बिना निगरानी के इसे --yes चाहिए।
• —विफल अनुरोध API एरर प्रिंट करता है और उससे मेल खाते कोड के साथ बाहर निकलता है।

security नेमस्पेस openemail --help में नहीं दिखता, क्योंकि उसे openemail verify चलाता है। उसके वर्ब step-up-status, begin-step-up और verify-step-up वे कॉल हैं जो verify करता है: verify --status स्थिति पढ़ता है, और verify कोड माँगता है, आपसे उसे डालने को कहता है और उसे जाँचता है। ये ब्राउज़र साइन-इन के लिए हैं। API कुंजी के साथ हर एक 400 step_up_not_applicable के साथ अस्वीकार होता है, और openemail verify बताता है कि कुंजी को कभी कोड की ज़रूरत नहीं होती।

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

इसे keys:manage वाली API कुंजी से चलाएँ, उदाहरण के लिए OPENEMAIL_API_KEY के ज़रिए। सीक्रेट जवाब से सीधे एक नई प्रोफ़ाइल में जाता है, इसलिए वह कभी स्क्रीन पर या किसी फ़ाइल में नहीं आता। कुंजी सिर्फ़ billing.acme.com से भेज सकती है, और 90 दिनों में ख़त्म हो जाती है।

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

पहले कुंजी को बंद करना --enabled से पलटा जा सकता है। उसे अब भी दिखाने वाली हर कॉल अस्वीकार होती है और उसकी गतिविधि में auth_failed के रूप में दिखती है, जिससे पता चलता है कि अब भी क्या उस पर निर्भर है। रद्द करना पलटा नहीं जा सकता, और सिर्फ़ रद्द की गई कुंजी ही हटाई जा सकती है।

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

भूमिका threads:read और emails:read के साथ भी लौटती है, क्योंकि उसकी बताई अनुमतियों में ये निहित हैं। Sam को भूमिका और पूरा डोमेन तभी मिलता है जब वे स्वीकार करते हैं। ब्राउज़र साइन-इन के साथ members add पहले सत्यापन कोड माँगती है।

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 और apiKeys पूछने के समय गिने जाते हैं, इसलिए ये दिखाते हैं कि हटाना किसे ले जाएगा। ड्राई रन DELETE को उसकी क्वेरी में reassignTo के साथ, भेजे बिना प्रिंट करता है। ब्राउज़र साइन-इन के साथ अपडेट और हटाना, दोनों सत्यापन कोड माँगते हैं, इसलिए जब कोई स्क्रिप्ट यह करे तो पहले openemail verify चलाएँ।

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 सिर्फ़ पता प्रिंट करता है, इसलिए वह शेल वेरिएबल में आ जाता है, और temp watch --first पहले संदेश पर रुकता है। openemail send की जगह किसी साइन-अप फ़ॉर्म में यह पता डालें, ताकि उसका पुष्टि कोड इसी तरह पकड़ सकें।

• —स्कोप के बिना साइन-इन या कुंजी एग्ज़िट कोड 4 के साथ रुकती है, छूटे स्कोप का नाम बताती है और उसे पाने का तरीका भी।
• —ये पुष्टि माँगती हैं: keys delete, rotate और revoke, me rotate, roles delete, members remove, revoke-address और revoke-invitation, temp delete, और temp-mail delete और delete-message। ना कहने पर वे कोड 10 के साथ बाहर निकलती हैं और कुछ नहीं बदलतीं। बिना निगरानी के और --yes के बिना, वे कुछ भी भेजे जाने से पहले एग्ज़िट कोड 2 के साथ रुकती हैं।
• —ब्राउज़र साइन-इन के साथ roles update और roles delete, और members add, update, remove, grant-address और revoke-address सत्यापन कोड भी माँगती हैं, जब तक इस साइन-इन ने पिछले 60 मिनट में कोई कोड सत्यापित न किया हो। --yes इसे कभी नहीं छोड़ता, और बिना निगरानी के कोई उसे टाइप नहीं कर सकता, इसलिए कमांड एग्ज़िट कोड 4 के साथ रुकती है। पहले openemail verify चलाएँ। API कुंजी से कभी नहीं पूछा जाता।
• —--dry-run वह अनुरोध उसकी बॉडी के साथ प्रिंट करता है जो बदलाव भेजता, और उसे भेजे या पुष्टि माँगे बिना कोड 0 के साथ बाहर निकलता है।
• —सूची एक पेज पढ़ती है। --limit 1 से 100 लेता है और इसे छोड़ने पर सर्वर 25 भेजता है, सिवाय temp-mail list-messages के, जो 1 से 50 लेती है और 50 भेजती है। --cursor पिछले पेज का nextCursor लेता है। --all हर पेज पढ़ता है, --max <n> उतने आइटम के बाद रुकता है, और --ndjson, या पाइप में --all, हर लाइन में एक JSON ऑब्जेक्ट प्रिंट करता है। --json के साथ सूची एक { items, hasMore, nextCursor } दस्तावेज़ प्रिंट करती है।
• —roles list-permissions, languages list, temp-mail list-domains और temp-mail list-attachments सब कुछ एक साथ, एक सादे ऐरे के रूप में, बिना पेज के लौटाती हैं।
• —अस्वीकार होने पर कमांड उसकी स्थिति के कोड के साथ बाहर निकलती है: 401 के लिए 3, जैसे रद्द की गई कुंजी, 403 के लिए 4, जैसे beyond_caller_authority या owner_only, 404 के लिए 5, 409 के लिए 6, जैसे not_revoked, role_in_use या invitation_too_soon, 400 या 422 के लिए 7, जैसे member_is_owner या role_limit_reached, और 429 के लिए 8, जैसे too_many_inboxes।
• —जो बदलाव दो बार करने पर कुछ दोहरा देगा, उसे नेटवर्क विफलता के बाद कभी दोबारा नहीं आज़माया जाता: keys create और rotate, me rotate, roles create और delete, members add, remove, revoke-address और resend-invitation, और temp-mail create, extend, delete और delete-message। इनमें से किसी को फिर चलाने से पहले जाँच लें। पढ़ना, और वे बदलाव जो दो बार करने पर भी एक जैसे रहते हैं, जैसे keys update, keys revoke, roles update, members update और grant-address, अपने आप दोबारा आज़माए जाते हैं।