सदस्य सूचीबद्ध करें
वर्कस्पेस में मौजूद हर व्यक्ति, उनकी भूमिका, और उन्हें दिए गए पते।
असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।
GET /members
वर्कस्पेस में मौजूद हर व्यक्ति, उनकी भूमिका, और उन्हें दिए गए पते।
सदस्य दो ग्रांट हैं, एक नहीं
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"role बताता है कि वे क्या कर सकते हैं: एक row, एक भूमिका, वही ऑब्जेक्ट जिसे /roles वर्णित करता है। addresses बताता है कि वे यह किन पर कर सकते हैं: हर पते के लिए एक प्रविष्टि, हर एक अपना access लिए हुए। क्लाइंट को इन्हें मिलाना नहीं चाहिए: emails:send रखने वाली भूमिका और खाली addresses का मतलब है कोई ऐसा जो कहीं से भी नहीं भेज सकता, और viewer भूमिका के नीचे भरा हुआ addresses भी वही मतलब रखता है। भेजने का पथ दोनों जाँचता है, और इनमें से केवल एक दिखाने वाली स्क्रीन पूरे आत्मविश्वास से गलत कारण बताएगी।
पता-rows में access लिखा है जबकि संग्रहित कॉलम role कहता है, और यह नाम-बदलाव ही मुद्दा है, कोई सफ़ाई नहीं: इस ऑब्जेक्ट में पहले से एक role फ़ील्ड है जिसका अर्थ बिलकुल अलग है, और एक ही नेस्टिंग स्तर की दूरी पर दो role, दो अलग शब्दावलियों के मान लिए हुए, पहले ही जल्दी पढ़ने वाले के लिए बग हैं। access या तो member है, जो पता पढ़ता है और उसके रूप में भेजता है, या viewer, जो केवल पढ़ता है।
implied: true का अर्थ है कि यह भूमिका किसी ने चुनी ही नहीं। साझाकरण भूमिकाओं से बहुत पहले आ गया था, इसलिए मेलबॉक्स तक पहुँच रखने वाले अधिकांश लोगों के पास पता-ग्रांट हैं और कोई सदस्य-row नहीं; बैकफ़िल चलने तक उन्हें उनकी मेल से वंचित रखने के बजाय सेवा उनके सबसे चौड़े ग्रांट से एक बिल्ट-इन भूमिका अनुमानित करती है और उसे role.id null के साथ बताती है। उसे किसी की चुनी हुई भूमिका के बजाय “एक्सेस से अनुमानित” दिखाएँ। जब तक कोई PATCH उस अनुमान को निर्णय नहीं बनाता, उनका पता-एक्सेस चौड़ा करना चुपचाप यह भी चौड़ा कर देता है कि वे क्या कर सकते हैं।
मालिक पहली row है, isOwner: true के साथ चिह्नित, और role.builtin owner। वे वही खाता हैं जिस पर वर्कस्पेस टिका है, वे परिभाषा से हर अनुमति रखते हैं, और POST, PATCH तथा DELETE तीनों उन्हें member_is_owner के साथ मना करते हैं। इसलिए बिना साझा किया गया वर्कस्पेस शून्य नहीं, एक सदस्य बताता है। सीटें गिनते समय isOwner को छोड़ें।
उदाहरण
members:read चाहिए। पहले मालिक, फिर बाकी सब ईमेल के क्रम में, न कि जुड़ने के समय के क्रम में — क्योंकि यह सूची किसी एक व्यक्ति को ढूँढ़ने के लिए पढ़ी जाती है, यह देखने के लिए नहीं कि क्या बदला।
curl "$OE/members" -H "$AUTH"{ "object": "list", "data": [ { "object": "member", "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t", "email": "[email protected]", "name": "Sam Okonjo", "image": null, "role": { "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "builtin": null }, "implied": false, "permissions": [ "emails:send", "emails:read", "threads:read", "threads:write", "labels:read", "labels:write", "contacts:read" ], "addresses": [ { "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44", "address": "[email protected]", "access": "member" }, { "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "address": "[email protected]", "access": "viewer" } ], "createdAt": "2026-08-12T14:20:00.000Z" }, { "object": "member", "userId": "7fQ2mN8vBz1aRd4tYwKx7fQ2mN8vBz1a", "email": "[email protected]", "name": null, "image": null, "role": { "id": null, "name": "Viewer", "builtin": "viewer" }, "implied": true, "permissions": [ "emails:read", "drafts:read", "threads:read", "labels:read", "contacts:read", "calendar:read", "templates:read", "rules:read", "connections:read", "settings:read" ], "addresses": [ { "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "address": "[email protected]", "access": "viewer" } ], "createdAt": null } ], "hasMore": false, "nextCursor": null}एक ही सूची में दो आबादियाँ, और ऐसा होना ही चाहिए: किसी के पास भूमिका हो सकती है और कोई पता नहीं, और किसी के पास पता हो सकता है और कोई भूमिका-row नहीं। केवल साझा हिस्से को सूचीबद्ध करना दोनों को छिपा देता, और अधिकांश वर्कस्पेस पर दूसरा समूह बड़ा है।
createdAt उनके लिए null होता है जिनके पास ग्रांट हैं पर जिनकी सदस्य-row कभी लिखी ही नहीं गई — वही लोग जिनके लिए implied true है। यह बताता है कि उन्हें भूमिका कब मिली, यह नहीं कि उन्हें पहला पता कब साझा हुआ।
permissions बूलियन के समुच्चय के बजाय सपाट, हल की हुई सूची है। “क्या इसमें templates:write है” पूछने वाला क्लाइंट शब्दावली से पीछे नहीं छूट सकता; { canEditTemplates: true } थमाया गया क्लाइंट चुपचाप छूट सकता है।
बिना कर्सर के, मानक लिफ़ाफ़े के साथ। किसी वर्कस्पेस की सदस्यता इस बात से बँधी है कि मालिक ने वास्तव में कितने लोगों के साथ उसे साझा किया, और उसे पेजिनेट करना उस चीज़ के आगे औपचारिकता होती जिसे क्लाइंट एक बार लाकर पूरा रेंडर कर देता है।