दस्तावेज़ पर जाएँ
API

सदस्य प्राप्त करें

एक व्यक्ति, उनकी भूमिका और उनके पते, खाता id से।

GETapi.openemail.uk/members/{userId}

असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।

GET /members/{userId}

एक व्यक्ति, उनकी भूमिका और उनके पते, खाता id से।

उदाहरण

members:read चाहिए। user id से: सूची में दी गई userId, उनका ईमेल पता नहीं।

curl
curl "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t" -H "$AUTH"
रिस्पॉन्स
{  "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"    }  ],  "createdAt": "2026-08-12T14:20:00.000Z"}

यहाँ ईमेल से खोज नहीं है। POST /members ही एकमात्र कॉल है जो ईमेल लेती है, क्योंकि वही एकमात्र कॉल है जिसके पास सचमुच अभी कोई user id नहीं होती।

जो user id इस वर्कस्पेस पर नहीं है वह सीधा 404 है। इस रिसोर्स में यही एक मामला है जो निस्संदेह “ऐसा कोई रिसोर्स नहीं” है। वही स्थिति जब किसी ऐसे राइट से उठे जिसे वापस पढ़ा न जा सका, तो 422 बनती है — जो वहाँ सही है और यहाँ गलत।

यह जानबूझकर पूरी सदस्य-सूची से पढ़ा जाता है, एकल-row क्वेरी से नहीं: एक सदस्य भूमिका-row और पता-ग्रांटों के समुच्चय का योग है, और इनमें से कोई भी दूसरे के बिना मौजूद हो सकता है; वह योग ठीक एक ही जगह निकाला जाता है। एकल-row क्वेरी उसका दूसरा कार्यान्वयन होती, और जिस आबादी को वह चुपचाप छोड़ देती वह हैं पुराने ग्रांट-धारक, जो आज तालिका के अधिकांश हैं।