پرش به مستندات
API

دریافت یک عضو

یک شخص، نقشش و نشانی‌هایش، بر اساس شناسهٔ حساب.

GETapi.openemail.uk/members/{userId}

فراخوانی واقعی را با کلید خودتان روی فضای کاری شما اجرا می‌کند.

GET /members/{userId}

یک شخص، نقشش و نشانی‌هایش، بر اساس شناسهٔ حساب.

نمونه

نیازمند members:read است. بر اساس شناسهٔ کاربر: همان 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 تنها فراخوانی‌ای است که ایمیل می‌گیرد، چون تنها فراخوانی‌ای است که فراخوان‌کننده‌اش واقعاً هنوز شناسهٔ کاربر ندارد.

شناسهٔ کاربری که روی این فضای کاری نیست یک 404 سادهٔ است. این تنها موردی در این منبع است که بی‌ابهام «چنین منبعی وجود ندارد» است. همان وضعیت وقتی از دل نوشتنی برخیزد که نتوانسته دوباره خوانده شود به 422 نگاشته می‌شود، که آنجا درست است و اینجا نادرست.

عمداً از دل فهرست کامل اعضا خوانده می‌شود نه با یک کوئری تک‌سطری: یک عضو اجتماع یک سطر نقش و مجموعه‌ای از دسترسی‌های اعطاشدهٔ نشانی است، که هر کدام می‌توانند بدون دیگری وجود داشته باشند، و این اجتماع دقیقاً در یک جا محاسبه می‌شود. یک کوئری تک‌سطری پیاده‌سازی دومی از آن می‌بود، و جمعیتی که بی‌صدا از قلم می‌انداخت دارندگان دسترسی‌های قدیمی‌اند که امروز بیشتر جدول را می‌سازند.