API

メンバーを取得する

1 人分のロールとアドレスを、アカウント id で取得します。

GETapi.openemail.uk/members/{userId}

実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。

GET /members/{userId}

1 人分のロールとアドレスを、アカウント id で取得します。

例

members:read が必要です。ユーザー 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 だけで、呼び出し側が本当にまだユーザー id を持っていない唯一の呼び出しだからです。

このワークスペースにないユーザー id は単なる 404 です。このリソースの中で、明確に「そのようなリソースはない」と言える唯一のケースです。書き込みが読み戻せずに同じ状況が起きた場合は 422 になります。そちらでは正しく、ここでは誤りです。

単一行のクエリではなく、意図的にメンバー一覧全体から読み出しています。メンバーとはロール行とアドレス付与の集合の「和」であり、どちらか一方だけが存在することもあります。その和を計算する場所はただ 1 か所です。単一行のクエリはその 2 つ目の実装になり、そこで静かに取りこぼされるのは、今日この表の大半を占めるレガシーな付与保持者です。